> Hm, maybe the following will be an acceptable solution:
>
> Non-Pro Applications should use the ALSA-API for Audio
> Output and Input.
>
> They will use the default ALSA Device, which by default
> should be the DMIX Plugin, which does samplerate conversion
> and mixing, if this is not provided by the Hardware.
We already have this in recent distros thanks to the work of
the ALSA team.
> For the Pro-Applications there is jack, but as soon as the
> jack daemon is started, it will automagically connect the
> default ALSA-Device and DMIX Plugin through the ALSA-Jack
> plugin to jack. This of course could also be done by an app
> like qjackctl.
This is a possible option, but isn't it a bit weird?
What about the other way around:
* DMIX is the default like you have told
* JACK starts automatically on demand (AFAIK JACK is already
able to do so, isn't it?)
* JACK runs per default on top of DMIX (which increases
latency)
* Low latency freaks ensure that no other audio app is running
and tell jack to start directly on top of the hardware
Advantages:
* ALSA applications still work and don't need to be rewritten
* Consumer audio apps can be rewritten for JACK step by step
* Desktop users who know how to deal with JACK can benefit
from its features, maybe listening to a web radio via xmms
running on top of JACK while simultaneously recording it to
the harddrive via qarecord also running on top of JACK
This is a solution I'd still find very interesting, but to do
this it needs some people who are interested in improving
JACK to fit this situation.
[...]
Best regards & thanks for your thoughts,
ce
Received on Mon Jun 20 04:15:16 2005
This archive was generated by hypermail 2.1.8 : Mon Jun 20 2005 - 04:15:17 EEST