| |||||||||||||
Interview with Lennart Poettering (LinuxFR.org)Interview with Lennart Poettering (LinuxFR.org)Posted Jul 6, 2011 14:34 UTC (Wed) by bronson (subscriber, #4806)In reply to: Interview with Lennart Poettering (LinuxFR.org) by trasz Parent article: Interview with Lennart Poettering (LinuxFR.org)
> Doing it in the kernel does not cause any problems
I guess you don't count poor CPU accounting and inability to configure it (especially latency) as problems? SYNC should be good enough for everybody?
Linux is starting to make a dent in the professional audio world precisely because of these "useless configuration options."
(Log in to post comments)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:44 UTC (Wed) by jrigg (subscriber, #30848) [Link]
> Linux is starting to make a dent in the professional audio world precisely because of these "useless configuration options."
Exactly. I've been using Linux for pro audio work for the last six years, thanks to the configuration options provided by ALSA. Desktop and pro audio requirements are mutually exclusive in many respects. In order to cater to both sets of users a certain amount of configurability is necessary.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:28 UTC (Wed) by trasz (guest, #45786) [Link]
FreeBSD OSS allows one to configure audio latencies. I have no idea what "poor CPU accounting" you're talking about. Are you sure you're not extrapolating problems specific to one implementation onto others?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:09 UTC (Wed) by cmccabe (guest, #60281) [Link]
> Linux is starting to make a dent in the professional audio world
> precisely because of these "useless configuration options."
I thought JACK was the reason why Linux was useful in the professional audio world? JACK doesn't seem to be tied to ALSA, since it has OSS, CoreAudio, and other backends in addition to its ALSA backend.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 21:32 UTC (Wed) by jrigg (subscriber, #30848) [Link]
JACK is an important reason but not the only one. ALSA allows multiple interface cards to be treated as a single multi-channel device (using pcm_multi) for example. JACK will only handle one input device and one output device at a time.
OSS might be able to combine multiple interfaces too, but last time I checked it was too limited in other ways to use with my interface hardware (eg. only 48kHz supported on RME MADI cards, no driver available at all for the PCIe version). OSS seems to lag behind ALSA in support for pro level hardware, in my experience.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:32 UTC (Wed) by drag (subscriber, #31333) [Link]
>JACK will only handle one input device and one output device at a time.
No, I don't think that is true at all. I haven't used Jack in a while, but it seems with it's routing capabilities and qjackctl (to enable easy access to those capabilities) it should have no problem at all handling multiple devices.
In a system with using multiple devices at the same time it may become problematic to try to get low latency and multiple simultanous output working with correct timing. Probably need some mechanism to keep the clocks on your sound cards in sync and such things.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:45 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Yes, pro-hardware is capable of using an external clock. So you pick one reference clock and all your gear keeps time with that.
Most consumer hardware does not offer this capability, you will need to investigate nasty hacks if you want to try to strap three cheap PCI soundcards together as an alternative to buying one six channel pro card.
JACK Posted Jul 6, 2011 22:53 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Oh, I forgot to address the actual point you made. No, JACK only works with one device.
If you have several physical devices which are genuinely sync'd you can just use ALSA to weave them together. If they aren't synchronised bad stuff may happen.
The reason for working with one device is that JACK's graph execution goes like this:
1. Interrupt from hardware indicates that, say, 128 frames are ready
If JACK was willing to work with more than one device, which interrupt does it wait for? What does it do with parts of the graph which require data from more than one input device? Or send data to more than one output device?
Lots of complexity, for a corner case no professional audio people care about (they either have only one device, or their devices can be clock-locked and woven into a single virtual device) and no consumers have the gear to test.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 19:32 UTC (Thu) by jrigg (subscriber, #30848) [Link]
I was referring specifically to combining several interfaces of the same type into a single virtual device, eg. using three 8-channel interfaces as a single 24-channel device, or a couple of 64-channel MADI interfaces as a single 128-channel device.
JACK has no trouble working with multiple devices as long as you only want to use one at a time. It can use different devices for capture and playback, but it can't combine several hardware devices into a single virtual device as I described above. That's what the pcm_multi plugin in ALSA is for (and as you mentioned, hardware clock sync is required).
|
|||||||||||||