24 Feb
2014
24 Feb
'14
11:34 p.m.
Hi *!
I'm trying to get my Gigaport HD+ to run at 48000kHz. The specs say it
is capable of 8ch @ 44k1/16, 6ch at 44k1/24 and 48k/24.
When I try to start it at 48k, it comes up ok but ends up running at
44k1. It shows 8 channels, so that's expected.
Now, how do I tell it to use only 6, so that I can get to 48k?
I've tried setting -o6, which gives the usual "cannot set playback
channel count".
Next I looked at amixer -D hw:3 controls, and there is a playback switch
map that is set to "on,on,on,on,on,on,on,on". I set it to
"on,on,on,on,on,on,off,off" and retry. No luck. Still fails to set
playback channel count, JACK still comes up with 8 outs and falls back
to 44k1.
What am I missing? Is there some .asoundrc magic that might come to the
rescue? Maybe define a device that has only 6 channels to begin with?
But how do I do that?
Any hints much appreciated.
Best,
Jörn
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
25 Feb
25 Feb
12:19 a.m.
On Mon, Feb 24, 2014 at 11:34:47PM +0100, Jörn Nettingsmeier wrote:
What am I missing? Is there some .asoundrc magic that
might come to
the rescue? Maybe define a device that has only 6 channels to begin
with? But how do I do that?
Jack's ALSA backend (and zita-alsa-pcmi) opens a device in MMAP
mode, and for hw: devices this is normally possible only using
*all* available channels.
The problem I guess is due to the way the HW related params
are set:
1. Allocate a hw_params struct
2. Fill in the params using set_*** functions
3. Submit the hw_params struct.
In step 2, the set_*** functions are aware of the acceptable
ranges/values and will report error if anything is not possible.
The backend code sets the sample rate before anything related
to channel counts is set or tested. So if the ALSA code still
reports that 8 channels are available after the sample rate
is set to 48 kHz, that looks to me like a bug in the driver.
The HW itself is not set up before step 3, so it is probably
still set to 44.1 kHz while the hw_params is filled in, and it
reports 8 channels.
If the API only allows setting all HW parameters in one step,
as is the case, then the driver should be aware of the channel
count vs. sample rate restrictions *without* relying on the HW,
but it probably isn't.
Ciao,
--
FA
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)
1:54 a.m.
On Mon, Feb 24, 2014 at 6:19 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
The problem I guess is due to the way the HW related params
are set:
1. Allocate a hw_params struct
2. Fill in the params using set_*** functions
3. Submit the hw_params struct.
In step 2, the set_*** functions are aware of the acceptable
ranges/values and will report error if anything is not possible.
The backend code sets the sample rate before anything related
to channel counts is set or tested. So if the ALSA code still
reports that 8 channels are available after the sample rate
is set to 48 kHz, that looks to me like a bug in the driver.
No, this is based on a misconception.
The legal ALSA driver parameters form a sparse multi-dimensional space. The
driver knows the legal intervals along each dimensional axis, but it does
not know the shape of the intersecting space.
Thus the only way to find out if a given combination of parameters is legal
is to try to set them and see if the hardware accepts them.
I only know the RME Hammerfall driver well, but in that case, where the
channel count changes depending on whether you do <88.2kHz or >= 88.2kHz,
there is no way that the driver can tell you that your attempt to use too
many channels is wrong until you submit the entire h/w params struct.
The HW itself is not set up before step 3, so it is probably
still set to 44.1 kHz while the hw_params is filled in, and it
reports 8 channels.
No. The driver just gives you some values based on a possible (or maybe
even most likely) scenario. The driver does not know the number of channels
in a definitive way. This is partly an ALSA API issue and partly a h/w
issue - in some cases, you just don't know (or it is very fiddly and
complex to find out - e.g. is there a daughterboard present that increases
the channel count in some cases).
12:48 p.m.
On Mon, Feb 24, 2014 at 07:53:58PM -0500, Paul Davis wrote:
Depends on the driver. For the hdspm driver for example, once the sample rate
is set to 96 kHz in the hw_params (and thus before any real HW configuration
is done), both snd_pcm_hw_params_get_channels_max() and ..._min() return 32
instead of 64. This depends *only* on the contents of the partially filled-in
hw_params struct, not on the actual rate used at the time. And it is the only
way user code can find out the value to use (apart from trying a zillion
combinations).
On Mon, Feb 24, 2014 at 6:19 PM, Fons Adriaensen
<fons(a)linuxaudio.org>wrote;wrote:
>
> The problem I guess is due to the way the HW related params
> are set:
>
> 1. Allocate a hw_params struct
> 2. Fill in the params using set_*** functions
> 3. Submit the hw_params struct.
>
v> > In step 2, the set_*** functions are aware of the acceptable
ranges/values
and will report error if anything is not possible.
The backend code sets the sample rate before anything related
to channel counts is set or tested. So if the ALSA code still
reports that 8 channels are available after the sample rate
is set to 48 kHz, that looks to me like a bug in the driver.
No, this is based on a misconception.
The legal ALSA driver parameters form a sparse multi-dimensional space. The
driver knows the legal intervals along each dimensional axis, but it does
not know the shape of the intersecting space. Thus the only way to find out if a given combination
of parameters is legal
is to try to set them and see if the hardware accepts them.
That works only if the driver _lets you set the correct values_ in the first
place. If for example snd_hdspm would not work as described above, it would
be impossible to set the channel count to the correct value. Both min and max
would be 64, and snd_pcm_hw_params_set_channels() would refuse to accept the
correct value, 32.
I only know the RME Hammerfall driver well, but in
that case, where the
channel count changes depending on whether you do <88.2kHz or >= 88.2kHz,
there is no way that the driver can tell you that your attempt to use too
many channels is wrong until you submit the entire h/w params struct.
Wrong, at least for snd_hdspm (and I did my homework before posting this
message and the previous one).
Ciao,
--
FA
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)
12:55 p.m.
On Tue, Feb 25, 2014 at 6:48 AM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
Wrong, at least for snd_hdspm (and I did my homework before posting this
message and the previous one).
Things appear to have changed (for the better) then, since back in the days
of legend.
2:23 p.m.
Jörn Nettingsmeier wrote:
I'm trying to get my Gigaport HD+ to run at
48000kHz. The specs say it is capable of 8ch @ 44k1/16, 6ch at 44k1/24 and 48k/24.
Please show the output of "lsusb -v" for this device.
When I try to start it at 48k, it comes up ok but ends
up running at 44k1. It shows 8 channels, so that's expected.
Now, how do I tell it to use only 6, so that I can get to 48k?
I've tried setting -o6, which gives the usual "cannot set playback channel
count".
In theory, any supported combination of parameters should work with Jack.
Does it work with "speaker-test -D hw:3 -c 6 -r 48000"?
Regards,
Clemens
2:25 p.m.
On 02/25/2014 12:54 PM, Paul Davis wrote:
On Tue, Feb 25, 2014 at 6:48 AM, Fons Adriaensen <fons(a)linuxaudio.org
<mailto:fons@linuxaudio.org>> wrote:
Wrong, at least for snd_hdspm (and I did my homework before posting this
message and the previous one).
Things appear to have changed (for the better) then, since back in the
days of legend.
Thanks Fons and Paul for the enlightenment. Is the behaviour that Fons
described supposed to be consistent between all ALSA drivers that
support variable channel counts? Then what I'm seeing is clearly a bug,
and I should take it to alsa-dev.
Otherwise, anything other than 44k1/16bits/8ch might just be unsupported
by the driver.
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...
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
2:39 p.m.
On Tue, Feb 25, 2014 at 8:25 AM, Jörn Nettingsmeier <
nettings(a)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.
that was the intent, anyway.
3:41 p.m.
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(a)stackingdwarves.net> wrote:
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.
--
FA
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)
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.
3:56 p.m.
On Tue, Feb 25, 2014 at 02:25:25PM +0100, Jörn Nettingsmeier 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...
The -i and -o options probably work on 'plug' devices (and on aloop),
but AFAIK they are useless for hw: devices.
While developing zita-alsa-pcmi I wanted to add parameters to select
channels - this just never worked, only one value (all channels)
being accepted in all of the tests I did. So now it works the opposite
way: you open the device and then read the number of channels that are
available. When using the mmap access mode it's easy enough to read/write
only the channels you want and to ignore the rest without any overhead,
so in practice this not a problem.
Ciao,
--
FA
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)
4 p.m.
Fons Adriaensen wrote:
On Tue, Feb 25, 2014 at 08:39:14AM -0500, Paul Davis
wrote:
Regardless of the access mode, you can get as many channels as the
hardware supports. Typically, consumer hardware supports 2/4/6/8
channels, while most pro chips don't bother to be flexible.
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. 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 USB devices, the number of channels is selected before the buffers
are allocated. The only constraint is that the device must actually
support that number of channels.
I don't know what the Gigaport actually supports.
Regards,
Clemens
4:09 p.m.
On Tue, Feb 25, 2014 at 9:41 AM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Tue, Feb 25, 2014 at 08:39:14AM -0500, Paul Davis
wrote:
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.)
the option doesn't alter what the JACK backend sees from ALSA (or
wherever). it changes which channels get represented by JACK ports.
On Tue, Feb 25, 2014 at 8:25 AM, Jörn
Nettingsmeier <
nettings(a)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.
4:52 p.m.
On Tue, Feb 25, 2014 at 10:09:16AM -0500, Paul Davis wrote:
the option doesn't alter what the JACK backend
sees from ALSA (or
wherever). it changes which channels get represented by JACK ports.
Wrong. If things were as you claim, this should just work:
(on a 64-ch card)
fons@hypatia:~> jackd -P70 -p256 -t2000 -u -dalsa -dhw:0,0 -r48000 -p256 -n2 -i16 -o16
...
ALSA: cannot set channel count to 16 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
The -i and -o values ARE used as parameters to ALSA, and
not just to determine how many of the available channels
are mapped to Jack ports. You can also verify this in the
sources.
Ciao,
--
FA
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)
5 p.m.
On Tue, Feb 25, 2014 at 10:52 AM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Tue, Feb 25, 2014 at 10:09:16AM -0500, Paul Davis
wrote:
clearly i have losted a RAM card or something. I could have sworn it worked
as i described because otherwise i could never have tested it on an RME
card without avoiding hw:N
i should run the memory checker on myself these days.
the option doesn't alter what the JACK
backend sees from ALSA (or
wherever). it changes which channels get represented by JACK ports.
Wrong. If things were as you claim, this should just work:
(on a 64-ch card)
fons@hypatia:~> jackd -P70 -p256 -t2000 -u -dalsa -dhw:0,0 -r48000 -p256
-n2 -i16 -o16
...
ALSA: cannot set channel count to 16 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
The -i and -o values ARE used as parameters to ALSA, and
not just to determine how many of the available channels
are mapped to Jack ports. You can also verify this in the
sources.
11:08 p.m.
hi clemens, thanks for your help.
On 02/25/2014 02:23 PM, Clemens Ladisch wrote:
~ # speaker-test -D hw:1 -c 6 -r 48000
speaker-test 1.0.27.2
Playback device is hw:1
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Channels count (6) not available for playbacks: Invalid argument
Setting of hwparams failed: Invalid argument
so the issue appears to be at the ALSA level, not with JACK.
btw, the same happens with 48k/8ch (which is out of spec according to
ESI), but also with 96k/2ch, which should be supported.
btw, the card claims 24bit support (whatever that is worth in this price
range), but i find i cannot specify 24bit int, only S16_*, float, and
S32_* - am i misunderstanding this option, or does it not represent
24bit fixed-point?
what is the best way to pursue this further?
thanks,
jörn
Bus 002 Device 011: ID 2573:0009
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x2573
idProduct 0x0009
bcdDevice 1.00
iManufacturer 1 ESI Audiotechnik GmbH
iProduct 2 GIGAPort HD+
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 116
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 250mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 46
bInCollection 1
baInterfaceNr( 0) 1
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bNrChannels 8
wChannelConfig 0x00ff
Left Front (L)
Right Front (R)
Center Front (C)
Low Freqency Enhancement (LFE)
Left Surround (LS)
Right Surround (RS)
Left of Center (LC)
Right of Center (RC)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 2
bSourceID 1
bControlSize 1
bmaControls( 0) 0x00
bmaControls( 1) 0x03
Mute Control
Volume Control
bmaControls( 2) 0x03
Mute Control
Volume Control
bmaControls( 3) 0x03
Mute Control
Volume Control
bmaControls( 4) 0x03
Mute Control
Volume Control
bmaControls( 5) 0x03
Mute Control
Volume Control
bmaControls( 6) 0x03
Mute Control
Volume Control
bmaControls( 7) 0x03
Mute Control
Volume Control
bmaControls( 8) 0x03
Mute Control
Volume Control
iFeature 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 2
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 8
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 44100
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 9
Transfer Type Isochronous
Synch Type Adaptive
Usage Type Data
wMaxPacketSize 0x0360 1x 864 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Device Status: 0x0000
(Bus Powered)
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
Jörn Nettingsmeier wrote:
see below. i'd be interested to hear what you find.
I'm trying to get my Gigaport HD+ to run at
48000kHz. The specs say it is capable of 8ch @ 44k1/16, 6ch at 44k1/24 and 48k/24.
Please show the output of "lsusb -v" for this device. When I try to
start it at 48k, it comes up ok but ends up running at 44k1. It shows 8 channels, so
that's expected.
Now, how do I tell it to use only 6, so that I can get to 48k?
I've tried setting -o6, which gives the usual "cannot set playback channel
count".
In theory, any supported combination of parameters should work with Jack.
Does it work with "speaker-test -D hw:3 -c 6 -r 48000"?
11:43 p.m.
On Tue, Feb 25, 2014 at 5:08 PM, Jörn Nettingsmeier <
nettings(a)stackingdwarves.net> wrote:
btw, the card claims 24bit support (whatever that is worth in this price
range), but i find i cannot specify 24bit int, only S16_*, float, and S32_*
- am i misunderstanding this option, or does it not represent 24bit
fixed-point?
S32_* covers 24-bits-packed-into-a-32bit-integer.
3723
days inactive
3724
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
4 participants
participants (4)
-
Clemens Ladisch -
Fons Adriaensen -
Jörn Nettingsmeier -
Paul Davis