[LAD] JACK on Gigaport HD+ at 4800kHz (reduced channel count)

Fons Adriaensen fons at linuxaudio.org
Tue Feb 25 14:41:17 UTC 2014

On Tue, Feb 25, 2014 at 08:39:14AM -0500, Paul Davis wrote:
> On Tue, Feb 25, 2014 at 8:25 AM, Jörn Nettingsmeier <
> nettings at stackingdwarves.net> wrote:
> >
> > If the maximum channel count is always fixed by the hardware, what is the
> > point of the corresponding jackd option? As I said, I don't remember if
> > ever doing something other than throwing the "cannot set channel count"
> > error...
> imagine you have an N (where N > 16) channel device but only channels 1-4
> are connected. the channel count option stops you from having to look at
> N-4 useless channels on the device all the time.

AFAIK, when using the MMAP access mode, you always get the full channel
count. Which makes sense, since what gets mapped into user space may
very well be an actual HW buffer having a fixed layout (which may be
interleaved, complex-interleaved, etc.)

For a USB device it will be some kernel memory that gets mapped of course,
so in theory a selection of channels could be done while defining that
buffer. But it doesn't seem to work that way.

For the case at hand, would it be possible to set the device to 48 kHz sample
rate using amixer ? If yes, that could solve the problem - once set to 48 kHz
ALSA may be able to find out the correct channel count, and allow you to set
it in hw_params. 

The snd_hdspm module behaves even more strangly: even while the API functions
that write the hw_params struct are aware of the sample rate/channel count
restrictions and allow you to initialise the hw_params as required, actually
using those hw_params to set the HW will still fail if a compatible sample
rate is not previously set using e.g. amixer.


A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

More information about the Linux-audio-dev mailing list