Thanks for this information. As soon as possible I will try WantedBy=usb-gadget.target in camilladsp_start.service.
btw is it possible to use dynamic sampelrate with camillaDSP and the usb gadget configuration?
logically i dont think so, the cdsp plugin offers a alsa sink that if used it will open camilladsp with the appropiate samplerate but if i route the usb gadget input to the cdsp alsa sink then camilladsp cant rate_adjust anymore because it isnt directly using the usb gadget device, correct?
logically i dont think so, the cdsp plugin offers a alsa sink that if used it will open camilladsp with the appropiate samplerate but if i route the usb gadget input to the cdsp alsa sink then camilladsp cant rate_adjust anymore because it isnt directly using the usb gadget device, correct?
oh, this here https://github.com/pavhofman/gaudio_ctl is exactly for this right? i need to try it
just received my ian canada transport pi digi today, just tried it with toslink so far but this seems way better then USB, so much that i would say the usb isolator (topping hs01) and usb filter (ifi isilencer 3.0) was kind of a waste of money...
---
Did you guys know you can run the pi as a Audio Gadget and Ethernet Gadget at the same time? that way you can save a additional ethernet cable or wifi dongle, you get internet over the host pc
I tried it and it seems to work just fine, i can write a small guide if someone wants to know
you have to use a other subnet then your normal network, im not sure yet if this works well with network streaming, but i think you can just route traffic from one subnet to another (somehow
)
---
Did you guys know you can run the pi as a Audio Gadget and Ethernet Gadget at the same time? that way you can save a additional ethernet cable or wifi dongle, you get internet over the host pc
I tried it and it seems to work just fine, i can write a small guide if someone wants to know
you have to use a other subnet then your normal network, im not sure yet if this works well with network streaming, but i think you can just route traffic from one subnet to another (somehow
)E.g. https://www.diyaudio.com/community/...io-gadget-rpi4-otg.342070/page-7#post-7301440
In addition to providing internet to the gadget, it allows configuring the USB gadget via browser of the USB host - running e.g. CamillaDSP GUI.
In addition to providing internet to the gadget, it allows configuring the USB gadget via browser of the USB host - running e.g. CamillaDSP GUI.
yes it seems to work just like any other network connection, you just need todo some ip routing to make it work
this is probably also somewhat on par with a real ethernet connection speed-wise... so faster then wifi specially if you do some kind of network streaming
i will write a small tutorial for others which build upon the guide already posted a few sites back in this thread to get ethernet gadget working too
for me the ethernet gadget is one step closer to a "perfect" endpoint scenario... i was using the rpi with a wifi dongle because it sounds slightly better then ethernet or the inbuilt wifi of the rpi but since we have to connect usb anyway for the audio gadget then we can also transfer the "lifting" of ethernet to the host pc
and its even easly disabled on the pc host side, even if it might not be nessecary, but i personally just use it currently to configure the dietpi os
for me the ethernet gadget is one step closer to a "perfect" endpoint scenario... i was using the rpi with a wifi dongle because it sounds slightly better then ethernet or the inbuilt wifi of the rpi but since we have to connect usb anyway for the audio gadget then we can also transfer the "lifting" of ethernet to the host pc
and its even easly disabled on the pc host side, even if it might not be nessecary, but i personally just use it currently to configure the dietpi os
I had to rework my Rpi3 Audio Gadget HowTo. Main motivation was that on my own gadget I changed some setup from a static configuration to a more dynamic configuration. So e.g. the system starts up nearly fully featured (fully "fatted"?). And it gets slimmed down (unload kernel modules, stop systemd units) specifically and only before audio processing. This way, system management options (= outside the audio sessions) are by no way jeopardized. I also added some ready-to-paste coding. Feedback welcome.
Will gaudio_ctl work if usb gadget mode is configured through configfs (instead of gaudio) ?
What kind of latency are we talking about here? Been reading through the thread and didn't see a clear answer.
Would real time vocal processing be possible? Let's say compressor, eq, gate. Typical channel strip stuff.
Doing it through a full linux installation I'd wager no, but I'd love to be wrong.
Even if <5ms roundtrip is impossible, can you get <15ms? With 15ms roundtrip you could have a headphone eq that can keep up with a fast paced fps game for example without feeling the footsteps are out of sync.
Just thinking of possible uses to see if it would be worth getting a hifiberry addon.
Would real time vocal processing be possible? Let's say compressor, eq, gate. Typical channel strip stuff.
Doing it through a full linux installation I'd wager no, but I'd love to be wrong.
Even if <5ms roundtrip is impossible, can you get <15ms? With 15ms roundtrip you could have a headphone eq that can keep up with a fast paced fps game for example without feeling the footsteps are out of sync.
Just thinking of possible uses to see if it would be worth getting a hifiberry addon.
if you tune your system quite well 15-20ms "should" be possible but i would say 50ms is more likely to work without problems
you need to account for double/triple buffers since it goes through two OS`s (and 3 alsa devices), so atleast in theory if you get 5ms working on your system 10-15ms should be in theory possible i think
About what I expected then. 50ms ain't bad for most uses, just not the ones I'd like. And from what I understand even if you trim all the fat, reducing buffers to get close to 20ms will lead to underruns.
Ok, one more thing then. How about clock stability. If I were to send its digital out to my babyface, would I be sending it cancer basically?
Ok, one more thing then. How about clock stability. If I were to send its digital out to my babyface, would I be sending it cancer basically?
IMO for live work it's better to use analog processing, or dedicated DSP chips. Involving an OS with inevitable process scheduling -> buffers -> latency may not be a viable path from the latency POV. Or doing the DSP directly on the source device.
Also I2S output may add lower latency than USB output, but I would guess just single millis diff.
Also I2S output may add lower latency than USB output, but I would guess just single millis diff.
IIRC more than 20ms starts to sound like a noticeable delay. Again IIRC, around 8-10ms up to about 18-20ms tends to sound like comb filtering. IME below 5ms delay tends to be pretty inaudible (unless maybe its part of ITD stereo localization).
Once again IME, some performers are very sensitive to small time delays. For them it may be to have an analog-path real-time monitor system (if the issue is they need a monitor/headphones). Or at least do the DSP locally without having go to a PC and back.
So it may depend on what you mean by real-time vocal processing? Is it for real time monitoring using digital effects, or some other purpose? What type of processing do you have in mind? If its not for monitoring then more delay may be okay. For instance, there is or was a hardware Autotune box. Don't know it it was fast enough for monitoring, but probably fast enough to drive a PA system for an audience.
Last edited:
50ms == 17.2m
20ms == 6.9m
10ms == 3.4m
5ms == 1.7m
As an enlightening real-world experiment, one may let his buddy clap his hands while both watching and listening to it from different distances. And then anyone may decide upon the individual effect it has on him. As an alternative, one may clap his hands in front of a large wall to listen to his own echo.
Before doing so, do not forget to stuff an RPi4 OTG gadget into your pocket... in order to prevent going off-topic.
Last edited:
Already been done with clicks and timers. For two successive clicks I could discern 10ms, but not 5. For using delays when mixing music, short delays make the music sound comb-filtered. That perceptual effect starts to sound more like a distinct delay instead of a comb filter at around 20ms or longer. Delaying clicks is a different effect from delaying a mix of continuous frequencies. When someone is performing music, either type of effect may occur depending on the musical content.
This is a strong point when using an USB gadget as a dedicated dsp processor for feedback into a mixing host: You will get comb filtering.
Attachments
Got plenty of potential uses for various levels of latency, heh.
The ideal usage would be as a vocal processor of course for recording monitoring. Quality matters little in this use case, but even 5ms RTT would be pushing it. This seems out of the question.
At 20-25ms it would probably be acceptable as a delay or reverb which is also quite desirable.
And if all else fails, at 50ms it could very well do as a vocal processor for VoIP calls. Skype, zoom and such. If you're not using it for monitoring your own voice during the call, the 50ms extra latency it would add to the audio stream won't make a big difference I reckon.
Headphone EQ is the other obvious use of course. Again same limitations. If you could go <15ms it could do for gaming too. At 50ms gonna be fine for media consumption.
Obviously you could do all this stuff in software on beefier machines or with dedicated hardware, but on the pi you got a great combo of not using main system resources, very low power consumption and infinite customization.
As you can probably tell I've decided to give it a try, just waiting for the missing components to arrive. Curious to see how it'll perform.
Hello !
I have a question about the USB audio-gadget.
I want to use my rasp zero 2W as an USB sound card (an later as an bluetooth receptor), do some room correction & loudness filter with camillaDSP, then output the signal through an allo miniboss DAC to my monitor speaker.
But for the loudness filter to work, the volume must be managed by camillaDSP.....
I setup an usb audio-gadget with these articles ( https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a & https://www.hackster.io/masonrf/rpi-z2w-usb-soundcard-78e757 ), then with the pdf file from Daihedz.
Globally, everything is working fine. With my computer (linux & windows), i can send music to the audio-gadget and control its volume. But in this case, camillaDSP doesn't handle the volume.....
The first article try to fix this by using a python script that retrieve the alsamixer volume and set it in camillaDSP ( see here ), but it only works when using windows. When using linux, the alsamixer's volume doesn't change, and I don't know why ?
So, does anyone know why it isn't working on linux? And also if there's a good ( better ? ) way to handle the volume in camillaDSP from the audio-gadget?
Regards
I have a question about the USB audio-gadget.
I want to use my rasp zero 2W as an USB sound card (an later as an bluetooth receptor), do some room correction & loudness filter with camillaDSP, then output the signal through an allo miniboss DAC to my monitor speaker.
But for the loudness filter to work, the volume must be managed by camillaDSP.....
I setup an usb audio-gadget with these articles ( https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a & https://www.hackster.io/masonrf/rpi-z2w-usb-soundcard-78e757 ), then with the pdf file from Daihedz.
Globally, everything is working fine. With my computer (linux & windows), i can send music to the audio-gadget and control its volume. But in this case, camillaDSP doesn't handle the volume.....
The first article try to fix this by using a python script that retrieve the alsamixer volume and set it in camillaDSP ( see here ), but it only works when using windows. When using linux, the alsamixer's volume doesn't change, and I don't know why ?
So, does anyone know why it isn't working on linux? And also if there's a good ( better ? ) way to handle the volume in camillaDSP from the audio-gadget?
Regards