<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 9:41 AM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Feb 25, 2014 at 08:39:14AM -0500, Paul Davis wrote:<br>
> On Tue, Feb 25, 2014 at 8:25 AM, Jörn Nettingsmeier <<br>
> <a href="mailto:nettings@stackingdwarves.net">nettings@stackingdwarves.net</a>> wrote:<br>
><br>
> ><br>
> > If the maximum channel count is always fixed by the hardware, what is the<br>
> > point of the corresponding jackd option? As I said, I don't remember if<br>
> > ever doing something other than throwing the "cannot set channel count"<br>
> > error...<br>
><br>
><br>
> imagine you have an N (where N > 16) channel device but only channels 1-4<br>
> are connected. the channel count option stops you from having to look at<br>
> N-4 useless channels on the device all the time.<br>
<br>
</div></div>AFAIK, when using the MMAP access mode, you always get the full channel<br>
count. Which makes sense, since what gets mapped into user space may<br>
very well be an actual HW buffer having a fixed layout (which may be<br>
interleaved, complex-interleaved, etc.)<br></blockquote><div><br></div><div>the option doesn't alter what the JACK backend sees from ALSA (or wherever). it changes which channels get represented by JACK ports.<br></div>
<div> </div></div><br></div></div>