Hi,

(routing back to alsa-devel, Ed's alsa-devel subscription is still pending so he can't sent to the list, forwarding with his permission)

On Fri, 4 Oct 2019, ed nwave wrote:

The example used of a voice changing app was just an illustration of how I need to connect "my driver" directly to a sound card driver that's all. I understand the user-space comment entirely.   The actual objective is one common driver ( my PCM driver ) being used by 4 music applications where I can dynamically switch the output PCM without restarting the applications or the applications even knowing the output cards not real.

so far this is pretty much directly from original design goals of JACK. But ok, then you mention this:

I must have direct access to audio hardware i.e. hw:1,0 for applications like RoonReady/ RAAT. So Pulseaudio's out. I require the ability to

Now this can be a problem of course if you cannot modify the apps. The you would have to route this via alsa-lib plugins.

follow ( like and MPD playlist ). As I understand Jack is set for a certain rate and format at the start when connecting and does not update rates automatically if the rate of the songs change; can jack connect directly to hw and handle DSD rates?. This is all part of a headless

I've been out of the loop for some years now, but no, I don't think JACK supports these. But you are anyways customizing quite a lot of SW, so you could e.g. consider extending JACK and/or some other audio server for this purpose, or just write a new one.

Other requirements are my applications must have no plugins or dmix and connect directly to hardware i.e. hw:1,0 - due to rate demands, no remixing. Another requirement is the latency required by one company to attain multi-room streaming being about 1ms max, this is for certification. Finally there's the need to change bit rate settings

I think reaching the latency requirement (and not doing mixing) can certainly be done in user-space, so I still read the "need to access harwdare directly" more as "existing user-space components are not suitable for my needs" than a strict requirement for doing this in kernel.

But alas, I get your context and I understand these constraints are real for you as well. Just wanted to make sure you have taken good enough look at user-space options.

All that's left for me to do is to connect pipe the data directly to the driver for the my sound card. Question is can it be done? And if so, where do I even start? How can I import snd_usb_audio and open it so it appears a the typical snd_card struct?

The longrunning trend has been to push stuff like this to user-space, so you will not find much examples. I haven't done this myself, so I'll let other people make recommendations. I'd start by looking at ALSA OSS emulation and the virtualized drivers we have (like sound/xen/).

Br, Kai