Re: [Jack-Devel] ALSA PCM multi plugin and xruns

On 12/11/2012 07:15 PM, Paul Davis wrote:
>
> jackd  [ ... args ... ] -d alsa -d hw:FIRST &
> alsa_in [ ... args ] -d hw:SECOND &
> alsa_out [ ... args ] -d hw:SECOND &
>
> [ .. repeat as needed]
>
> much more general than your brief summary, since alsa_in/alsa_out will
> resample as necessary, thus not requiring that the devices share a
> sample clock.
>
> there are also fons' version of alsa_in/out, which some people feel do
> an even better job with the resampling and more.
>
> now of course, if the devices are synced then none of this would be
> necessary. if they are synced and ALSA gets things things wrong, the
> ALSA needs fixing.

ho-humm. for years, we all have been telling newbies in a more or less 
friendly way that cascading non-hardware-synced consumer gear to obtain 
cheap multichannel devices is evil. now that the word has spread and 
people try to do things the proper way, all of a sudden everybody 
advocates resampling. it's a great quick-and-dirty solution iff you can 
spare the cycles and don't care for bit-transparency, but in a 
professional context with synced hardware, it is an abomination. shame 
on you mr davis :)

don't get me wrong, i love alsa_in/out and zita-ajbridge for what they 
do, but they are a band aid for very specific use cases (notably, to get 
local i/o for _monitoring purposes_ on a netjack slave). putting them in 
the signal path for the final product isn't to be undertaken lightly.

so yes, alsa needs fixing.




-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

1355250489.27204_0.ltw:2, <50C77AAB.4020605 at stackingdwarves dot net>