From: Ziser, J. <xe...@ya...> - 2009-04-25 15:53:13
|
Hello, I'm wondering what the rationale was behind making FreeBob/FFADO a JACK driver rather than an ALSA driver. It seems like JACK has no problem using ALSA as a backend, and in fact, in most JACK-related documentation that I find, it's pretty much just assumed that you're using ALSA. On the other hand, it is not possible to make JACK a backend of ALSA. Since most applications are written for ALSA/OSS, this means that what I thought was a sound device with support under Linux is really effectively not Linux-compatible at all right now. I've realized that if I want sound on my system, I'll have to write the driver myself, using the FFADO code as a starting point. So what I'm wondering is whether I'm going to run into some wall that you guys already ran into and that's the reason the driver wasn't written that way in the first place. Thanks for any advice, Jesse |
From: Pieter P. <pi...@jo...> - 2009-04-25 16:21:34
|
Ziser, Jesse wrote: > Hello, > > I'm wondering what the rationale was behind making FreeBob/FFADO a JACK driver rather than an ALSA > driver. The main rationale is that it is easier to program in userspace than in kernel space. Given the complexity of firewire streaming I still think it is a good idea. It is also much easier to write a jack backend than an ALSA userspace driver. ALSA is pretty complex and not very well documented IMHO. > > It seems like JACK has no problem using ALSA as a backend, and in fact, in most JACK-related > documentation that I find, it's pretty much just assumed that you're using ALSA. On the other > hand, it is not possible to make JACK a backend of ALSA. Since most applications are written for > ALSA/OSS, this means that what I thought was a sound device with support under Linux is really > effectively not Linux-compatible at all right now. You can use the ALSA-jack plugin to use expose jack as ALSA. > > I've realized that if I want sound on my system, I'll have to write the driver myself, using the > FFADO code as a starting point. So what I'm wondering is whether I'm going to run into some wall > that you guys already ran into and that's the reason the driver wasn't written that way in the > first place. You could try and make the native FFADO ALSA userspace plugin code work, it's in the FFADO repository trunk. I haven't had the time to make it work yet, but it should be close to working. We have an accepted Google SOC project where the goal is a kernel-space streaming driver for FFADO, exposing an ALSA API. We feel that at this point we have sufficient knowledge and reference code to start working on a kernel space driver. In any case, feel free to join in. Greets, Pieter |
From: Ziser, J. <xe...@ya...> - 2009-04-25 18:09:57
|
--- Pieter Palmers <pi...@jo...> wrote: > Ziser, Jesse wrote: > > Hello, > > > > I'm wondering what the rationale was behind making FreeBob/FFADO a JACK driver rather than an > ALSA > > driver. > > The main rationale is that it is easier to program in userspace than in > kernel space. Given the complexity of firewire streaming I still think > it is a good idea. > > It is also much easier to write a jack backend than an ALSA userspace > driver. ALSA is pretty complex and not very well documented IMHO. Aha. > > > > It seems like JACK has no problem using ALSA as a backend, and in fact, in most JACK-related > > documentation that I find, it's pretty much just assumed that you're using ALSA. On the other > > hand, it is not possible to make JACK a backend of ALSA. Since most applications are written > for > > ALSA/OSS, this means that what I thought was a sound device with support under Linux is really > > effectively not Linux-compatible at all right now. > > You can use the ALSA-jack plugin to use expose jack as ALSA. Interesting. That's the opposite of what I thought the JACK plugin did. The documentation for all things ALSA is indeed terrible. Despite trying for an hour or two (and fixing a severe bug in the internal ALSA config files that came with the damn OS), I haven't been able to get that plugin to do anything. Oh, well, on to better things. > > I've realized that if I want sound on my system, I'll have to write the driver myself, using > the > > FFADO code as a starting point. So what I'm wondering is whether I'm going to run into some > wall > > that you guys already ran into and that's the reason the driver wasn't written that way in the > > first place. > > You could try and make the native FFADO ALSA userspace plugin code work, > it's in the FFADO repository trunk. I haven't had the time to make it > work yet, but it should be close to working. > > We have an accepted Google SOC project where the goal is a kernel-space > streaming driver for FFADO, exposing an ALSA API. We feel that at this > point we have sufficient knowledge and reference code to start working > on a kernel space driver. > > In any case, feel free to join in. Oh, cool. In that case, I have to decide whether to help out on one of those, or just wait for the kernel driver you're about to create to be finished and magically appear. ;-) I guess I'll start looking at your code. Thanks! |