It seems unclear if the program or the data is the problem...
I agree, shift the data (digital music files) to the Ubuntu PC, use a USB stick, I just bought a 64 GB item, USB-C, for $5.00. You can also use a HDD, if you have one handy.
Or send the data over Bluetooth, dongle or built in TX/RX on both PC, if you want to store data on Windows PC.
As for apps / programs, there must be many for Linux, use what you are comfortable with, Ubuntu is now a popular and well established OS.
I agree, shift the data (digital music files) to the Ubuntu PC, use a USB stick, I just bought a 64 GB item, USB-C, for $5.00. You can also use a HDD, if you have one handy.
Or send the data over Bluetooth, dongle or built in TX/RX on both PC, if you want to store data on Windows PC.
As for apps / programs, there must be many for Linux, use what you are comfortable with, Ubuntu is now a popular and well established OS.
Again, thanks to everyone for their suggestions.
The most important point for starting this thread was the fact that I am bound to using Windows, and - because I am a fan - Foobar2000.
So using a different program to play music on a linux / RPi is surely possible, but just not practical for me.
A decided to switch from trying to use a laptop running Ubuntu, to a Pi5. The main reason being its support for USB gadget.
That way I can stay on Windows (and easily switch between work and music) and offload the DSP to separate hardware.
Linux is a rabbit hole I try to stay away from. The possibilities are endless, but so are the pitfals for the unexperienced. But the support for Camilla DSP on a Pi is great, especially from @mdsimon2 and @HenrikEnquist .
Looking forward to making my dedicated, fully USB, CDSP box! (still waiting for deliveries
)
The most important point for starting this thread was the fact that I am bound to using Windows, and - because I am a fan - Foobar2000.
So using a different program to play music on a linux / RPi is surely possible, but just not practical for me.
A decided to switch from trying to use a laptop running Ubuntu, to a Pi5. The main reason being its support for USB gadget.
That way I can stay on Windows (and easily switch between work and music) and offload the DSP to separate hardware.
Linux is a rabbit hole I try to stay away from. The possibilities are endless, but so are the pitfals for the unexperienced. But the support for Camilla DSP on a Pi is great, especially from @mdsimon2 and @HenrikEnquist .
Looking forward to making my dedicated, fully USB, CDSP box! (still waiting for deliveries
)
I shall be watching with interest, since a Pi5 USB gadget with CamillaDSP is exactly what I've decided to build too, and for quite similar reasons. I have done this previously with a Pi4 and as you say, the support for camilladsp is great, and phofman was also very helpful with the USB gadget side of things. I was very pleased with the result, in terms of the audio.
But I never made it a proper thing; it remained just an inelegant collection of bits surrounded by wires on the bench, that consequently were a slight faff to use. Partly because (for greater convenience) I used a small keyboard and monitor to set it up and lazily just left them there. So this time with the Pi5 I'm going to sort out (as a minimum) a decent case, power supply and convenient way to start it up and shut it down safely.
But I never made it a proper thing; it remained just an inelegant collection of bits surrounded by wires on the bench, that consequently were a slight faff to use. Partly because (for greater convenience) I used a small keyboard and monitor to set it up and lazily just left them there. So this time with the Pi5 I'm going to sort out (as a minimum) a decent case, power supply and convenient way to start it up and shut it down safely.
For windows another option would be using any VB-Audio app which implements the VBAN protocol (e.g. Voicemeeter) and receive the stream with PipeWire on any linux, e.g. https://blog.stanleysolutionsnw.com/a-better-way-to-integrate-with-voicemeeter.html . CamillaDSP can be used as an app for pulseaudio /pipewire, or native PW DSP like EasyEffects are quite popular https://github.com/wwmm/easyeffects
I would advice against RPi5 if you don't need all that power, because it usually needs active cooling and that causes noise. I'm still in process of implementing my RPi4 that I have underclocked as much as the hardware allows (it's still faster than any of the miniDSP processors), to reduce power draw and heat generation. In fact, I acquired a RPi Zero 2W, which is even lower in power, but there are much less connection options, so it needs a DAC hat.
Just to clarify, an audio sink device needs to handle a stream at only one rate/depth at a time, but can advertise and switch to one of many options, right? Is this what's coming up?
In UAC2 the device rate is advertised and configured by a clock feature (basically a USB control element - getting a list of available values to the host, setting a single value to the device), while the channel cnt and format are fixed for the given configuration/setting. The protocol allows the device to advertise more alternative settings (altsets), which enables the device to offer various channel cnt/format/rates combinations. The linux UAC2 host driver conveniently lists these altsets in the /proc/asound/cardXXX/stream0 infofile.
Based on the params requested by an audio client process the UAC2 host driver picks an appropriate altset of those advertised ones and tells the device to switch to this configuration (i.e. the fixed channel cnt/format/rates combo). Also the driver sets the device clock control to the required samplerate (multiple rates per each altset available). That fixes hw params of the corresponding alsa device on the internal side of the gadget driver to these selected values and any client process running on the gadget device can request only this combination, all other combinations are refused. Of course the client must identify these params first which brings some complications.
Currently a loaded UAC2 gadget supports only one altset, i.e. multiple rates, but fixed channel cnt and format. Multiple altsets will come, but it will take a while.
Based on the params requested by an audio client process the UAC2 host driver picks an appropriate altset of those advertised ones and tells the device to switch to this configuration (i.e. the fixed channel cnt/format/rates combo). Also the driver sets the device clock control to the required samplerate (multiple rates per each altset available). That fixes hw params of the corresponding alsa device on the internal side of the gadget driver to these selected values and any client process running on the gadget device can request only this combination, all other combinations are refused. Of course the client must identify these params first which brings some complications.
Currently a loaded UAC2 gadget supports only one altset, i.e. multiple rates, but fixed channel cnt and format. Multiple altsets will come, but it will take a while.