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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
