Thread: [Alsa-user] RME AES-32 questions
Brought to you by:
perex
From: John S. <lin...@fr...> - 2008-02-29 13:59:38
|
Hello, I have an RME AES-32 PCI board. http://www.rme-audio.de/en_products_hdsp_aes32.php I installed the main board only (not the daughter board) which gives me 8 mono in's and 8 mono out's (4 male + 4 female XLR connectors). My kernel is 2.6.22.1-rt9 (compiled from source). I have set the following sound-related kernel options. CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_HWDEP=y CONFIG_SND_RAWMIDI=y [...] CONFIG_SND_HDSPM=y The board seems to be correctly detected at boot-time. Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC). ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5 PCI: setting IRQ 5 as level-triggered ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5 ALSA device list: #0: RME HDSPM AES32 at 0xe5300000, irq 5 /proc/asound/cards 0 [default ]: HDSPAES32 - HDSPM MADI RME HDSPM AES32 at 0xe5300000, irq 5 /proc/asound/devices 0: [ 0] : control 4: [ 0- 0]: hardware dependent 8: [ 0- 0]: raw midi 9: [ 0- 1]: raw midi 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 33: : timer /proc/asound/hwdep 00-00: HDSPM hwdep interface /proc/asound/pcm 00-00: RME HDSPM AES32 : RME HDSPM AES32 : playback 1 : capture 1 /proc/asound/timers G0: system timer : 10000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE /proc/asound/card0/hdspm RME HDSPM AES32 (Card #1) Rev.e9 IRQ: 5 Registers bus: 0xe5300000 VM: 0xd0820000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=15809 HW pointer: id = 0, rawptr = 0 (0->32704) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 Register: ctrl1=0x10102dc, status1=0x10000, status2=0x80, timecode=0x3 --- Settings --- Size (Latency): 4096 samples (2 periods of 16384 bytes) Line out: on , Precise Pointer: off ClearTrackMarker off, Emphasis off, Dolby off Sample Clock Source: Internal 48 kHz System Clock Mode: Master Preferred Sync Reference: AES1 System Clock Frequency: 48000 Double speed: Single wire Quad speed: Single wire --- Status: Word: No Lock Frequency: 0 AES1: Sync Frequency: 48000 AES2: No Lock Frequency: 0 AES3: No Lock Frequency: 0 AES4: No Lock Frequency: 0 AES5: No Lock Frequency: 0 AES6: No Lock Frequency: 0 AES7: No Lock Frequency: 0 AES8: No Lock Frequency: 0 AutoSync ref = AES1 # ll /dev/snd/ total 0 crw-rw---- 1 root root 116, 0 Feb 28 18:19 controlC0 crw-rw---- 1 root root 116, 4 Feb 28 18:19 hwC0D0 crw-rw---- 1 root root 116, 8 Feb 28 18:19 midiC0D0 crw-rw---- 1 root root 116, 9 Feb 28 18:19 midiC0D1 crw-rw---- 1 root root 116, 24 Feb 28 18:19 pcmC0D0c crw-rw---- 1 root root 116, 16 Feb 28 18:19 pcmC0D0p crw-rw---- 1 root root 116, 33 Feb 28 18:19 timer I was expecting one device node per mono channel, but this is not the case. Is this normal? (udev configuration?) When I boot, every channel has its volume set to 0. Is this done by the board's firmware? I can't seem to record or play anything back until I have set the volume to something different than 0. I used amixer to change the volume. Simple mixer control 'Chn',1 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 65536 Mono: 32768 [50%] What is the meaning of the level? Does 100% mean the signal is left unmodified? and 50% means the amplitude is multiplied by 0.50? But then how does one specify amplification of the signal? Is it possible to un-mute all the channels in one command? I had several problems with configuration files and alsa-lib "devices" (hw:x,y plughw:x,y and such). I can't just use /dev device nodes with the alsa lib? Which configuration files are mandatory? ALSA lib seems unhappy without alsa.conf So I set the ALSA_CONFIG_PATH env var and that made ALSA happy. Some commands still fail because they can't find aliases.conf is that a mandatory file? Do I need other config files? One last question: is it possible to capture AES frames instead of just the PCM payload inside frames? (What happens when the payload isn't PCM but Dolby E and I request PCM samples?) Thanks for reading this far! Regards. |
From: John S. <lin...@fr...> - 2008-02-29 14:45:32
Attachments:
amixer.txt
amixer.contents.txt
|
John Sigler wrote: > I used amixer to change the volume. I've attached the output of amixer and amixer contents in case they are relevant. Regards. |
From: John S. <lin...@fr...> - 2008-03-03 14:49:23
|
(I'll try answering some of my questions.) John Sigler wrote: > I have an RME AES-32 PCI board. > http://www.rme-audio.de/en_products_hdsp_aes32.php > > [...] > > When I boot, every channel has its volume set to 0. > Is this done by the board's firmware? http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L3396 http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L965 Apparently, it's not the board's firmware, it's the device driver which mutes every channel at initialization. Does anybody know why this is done? > I used amixer to change the volume. > > Simple mixer control 'Chn',1 > Capabilities: volume volume-joined > Playback channels: Mono > Capture channels: Mono > Limits: 0 - 65536 > Mono: 32768 [50%] > > What is the meaning of the level? > Does 100% mean the signal is left unmodified? > and 50% means the amplitude is multiplied by 0.50? http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L377 #define UNITY_GAIN 32768 #define MINUS_INFINITY_GAIN 0 So, volume = 32768 means "leave the signal as is" and volume = 0 means "mute the channel". Is that correct? What would volume = 16384 and volume = 49152 mean? (What is the scale?) Regards. |
From: James Courtier-D. <jam...@gm...> - 2008-03-03 16:06:33
|
On 03/03/2008, John Sigler <lin...@fr...> wrote: > (I'll try answering some of my questions.) > > > John Sigler wrote: > > > I have an RME AES-32 PCI board. > > http://www.rme-audio.de/en_products_hdsp_aes32.php > > > > > [...] > > > > > When I boot, every channel has its volume set to 0. > > Is this done by the board's firmware? > > > http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L3396 > http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L965 > > Apparently, it's not the board's firmware, it's the device driver > which mutes every channel at initialization. > > Does anybody know why this is done? It was done to protect one's ears. > > > > I used amixer to change the volume. > > > > Simple mixer control 'Chn',1 > > Capabilities: volume volume-joined > > Playback channels: Mono > > Capture channels: Mono > > Limits: 0 - 65536 > > Mono: 32768 [50%] > > > > What is the meaning of the level? > > Does 100% mean the signal is left unmodified? > > and 50% means the amplitude is multiplied by 0.50? > > > http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L377 > > #define UNITY_GAIN 32768 > #define MINUS_INFINITY_GAIN 0 > > So, volume = 32768 means "leave the signal as is" and volume = 0 > means "mute the channel". Is that correct? > > What would volume = 16384 and volume = 49152 mean? > (What is the scale?) > There is no scale there. It can have a range of value between 0 and 65536 32768 being about 50% of 65536. Now, the ALSA mixer has been improved, and we can now report gain levels instead of these mostly meaningless percentage values. Try running "alsamixer", it will show dB values for each mixer control if the driver has been updated to report the information. So, 0 dB means "leave the signal as is" -X dB means "attenuate the signal by X db" X db means "gain the signal by X db" Now that we have these dB gain levels, we could potentially set all mixer controls to 0dB, i.e. not gain and not attenuation, with only the master output control being set to a lower value so as to avoid ears breaking. James |
From: John S. <lin...@fr...> - 2008-03-04 14:42:12
|
James Courtier-Dutton wrote: > John Sigler wrote: > >> I have an RME AES-32 PCI board. >> http://www.rme-audio.de/en_products_hdsp_aes32.php >> >> When I boot, every channel has its volume set to 0. >> >> http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L3396 >> http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L965 >> >> Apparently, it's not the board's firmware, it's the device driver >> which mutes every channel at initialization. >> >> Does anybody know why this is done? > > It was done to protect one's ears. Could you expand on your explanation? Intuitively, I would have initialized every input channel and output channel to "leave the signal as is" (what you refer to as 0 dB). >> I used amixer to change the volume. >> >> Simple mixer control 'Chn',1 >> Capabilities: volume volume-joined >> Playback channels: Mono >> Capture channels: Mono >> Limits: 0 - 65536 >> Mono: 32768 [50%] >> >> What is the meaning of the level? >> Does 100% mean the signal is left unmodified? >> and 50% means the amplitude is multiplied by 0.50? >> >> http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L377 >> >> #define UNITY_GAIN 32768 >> #define MINUS_INFINITY_GAIN 0 >> >> So, volume = 32768 means "leave the signal as is" and volume = 0 >> means "mute the channel". Is that correct? >> >> What would volume = 16384 and volume = 49152 mean? >> (What is the scale?) > > There is no scale there. > It can have a range of value between 0 and 65536 > 32768 being about 50% of 65536. As a matter of fact, 32768 is exactly 50% of 65536, but I'm not sure I understand the point you're making. The driver source code seems to imply that 32768 is special in that it is named UNITY_GAIN. That would seem to indicate that this volume level corresponds to 0 dB, wouldn't it? > Now that we have these dB gain levels, we could potentially set all > mixer controls to 0dB, i.e. not gain and not attenuation, with only > the master output control being set to a lower value so as to avoid > ears breaking. I don't know where the master output control is. Do you see it in the outputs of 'amixer' or 'amixer contents' I provided in one of my previous messages? Regards. |
From: James Courtier-D. <jam...@gm...> - 2008-03-04 15:03:18
|
On 04/03/2008, John Sigler <lin...@fr...> wrote: > James Courtier-Dutton wrote: > > > John Sigler wrote: > > > >> I have an RME AES-32 PCI board. > >> http://www.rme-audio.de/en_products_hdsp_aes32.php > >> > >> When I boot, every channel has its volume set to 0. > >> > > >> http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L3396 > >> http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L965 > >> > >> Apparently, it's not the board's firmware, it's the device driver > >> which mutes every channel at initialization. > >> > >> Does anybody know why this is done? > > > > It was done to protect one's ears. > > > Could you expand on your explanation? Some time ago, there was no way to tell, from user space, if 100% or 50% was 0db, -50dB or +50dB. As a result, the safest value to use was the minimum value being either 0% or mute. That has changed with alsa 1.0.16, as dB gain information is now available. > > Intuitively, I would have initialized every input channel and output > channel to "leave the signal as is" (what you refer to as 0 dB). > > > As a matter of fact, 32768 is exactly 50% of 65536, but I'm not sure I > understand the point you're making. The driver source code seems to > imply that 32768 is special in that it is named UNITY_GAIN. That would > seem to indicate that this volume level corresponds to 0 dB, wouldn't it? But the value of 50% does not correspond to 0 dB for all sound cards. > > > > Now that we have these dB gain levels, we could potentially set all > > mixer controls to 0dB, i.e. not gain and not attenuation, with only > > the master output control being set to a lower value so as to avoid > > ears breaking. > > > I don't know where the master output control is. Do you see it in the > outputs of 'amixer' or 'amixer contents' I provided in one of my > previous messages? > version 1.0.16 of amixer will have the dB values. You also have to have version 1.0.16 of alsa-driver and alsa-lib. |
From: John S. <lin...@fr...> - 2008-03-04 15:50:04
|
James Courtier-Dutton wrote: > Some time ago, there was no way to tell, from user space, if 100% > or 50% was 0db, -50dB or +50dB. As a result, the safest value to > use was the minimum value being either 0% or mute. That has changed > with alsa 1.0.16, as dB gain information is now available. I'm not sure where user space fits in. I'm talking about the sound/pci/rme9652/hdspm.c driver which mutes every channel at initialization by calling all_in_all_mixer(hdspm, 0); cf. http://lxr.linux.no/linux/sound/pci/rme9652/hdspm.c#L3396 AFAIU, the driver "knows" what level corresponds to 0 db. > But the value of 50% does not correspond to 0 dB for all sound > cards. I'm not discussing all sound cards, I'm discussing the sound cards driven by hdspm. Is it safe to assume that, for the cards driven by hdspm, level 32768 corresponds to 0 dB? Regards. |
From: James Courtier-D. <Ja...@su...> - 2008-03-04 17:57:16
|
Takashi Iwai wrote: > At Tue, 4 Mar 2008 15:03:15 +0000, > James Courtier-Dutton wrote: >>> > Now that we have these dB gain levels, we could potentially set all >>> > mixer controls to 0dB, i.e. not gain and not attenuation, with only >>> > the master output control being set to a lower value so as to avoid >>> > ears breaking. >>> >>> >>> I don't know where the master output control is. Do you see it in the >>> outputs of 'amixer' or 'amixer contents' I provided in one of my >>> previous messages? >>> >> version 1.0.16 of amixer will have the dB values. >> You also have to have version 1.0.16 of alsa-driver and alsa-lib. > > hdspm driver still doesn't support TLV dB information. > In addition, rme9652/hdsp/hdspm drivers use control elements in a > non-standard way for indirect accessing, so each mixer value isn't > visible in amixer or alsactl. > So, in that case mapping values from 0 to 65536 to gain values is not yet done for you. You will have to find some other method to convert them to gain values, and as the driver does not document the mapping, you probably have to use trial and error or look at a datasheet if they exist. James |
From: Takashi I. <ti...@su...> - 2008-03-05 06:45:09
|
At Tue, 04 Mar 2008 17:57:15 +0000, James Courtier-Dutton wrote: > > Takashi Iwai wrote: > > At Tue, 4 Mar 2008 15:03:15 +0000, > > James Courtier-Dutton wrote: > >>> > Now that we have these dB gain levels, we could potentially set all > >>> > mixer controls to 0dB, i.e. not gain and not attenuation, with only > >>> > the master output control being set to a lower value so as to avoid > >>> > ears breaking. > >>> > >>> > >>> I don't know where the master output control is. Do you see it in the > >>> outputs of 'amixer' or 'amixer contents' I provided in one of my > >>> previous messages? > >>> > >> version 1.0.16 of amixer will have the dB values. > >> You also have to have version 1.0.16 of alsa-driver and alsa-lib. > > > > hdspm driver still doesn't support TLV dB information. > > In addition, rme9652/hdsp/hdspm drivers use control elements in a > > non-standard way for indirect accessing, so each mixer value isn't > > visible in amixer or alsactl. > > > So, in that case mapping values from 0 to 65536 to gain values is not > yet done for you. You will have to find some other method to convert > them to gain values, and as the driver does not document the mapping, > you probably have to use trial and error or look at a datasheet if they > exist. 32768 = unity gain is found in hdspm.txt. But the actual dB level to be applied for other values isn't mentioned there. Takashi |
From: Takashi I. <ti...@su...> - 2008-03-04 15:48:29
|
At Tue, 4 Mar 2008 15:03:15 +0000, James Courtier-Dutton wrote: > > > > Now that we have these dB gain levels, we could potentially set all > > > mixer controls to 0dB, i.e. not gain and not attenuation, with only > > > the master output control being set to a lower value so as to avoid > > > ears breaking. > > > > > > I don't know where the master output control is. Do you see it in the > > outputs of 'amixer' or 'amixer contents' I provided in one of my > > previous messages? > > > version 1.0.16 of amixer will have the dB values. > You also have to have version 1.0.16 of alsa-driver and alsa-lib. hdspm driver still doesn't support TLV dB information. In addition, rme9652/hdsp/hdspm drivers use control elements in a non-standard way for indirect accessing, so each mixer value isn't visible in amixer or alsactl. Takashi |
From: John S. <lin...@fr...> - 2008-03-04 16:25:06
|
Takashi Iwai wrote: > hdspm driver still doesn't support TLV dB information. > In addition, rme9652/hdsp/hdspm drivers use control elements in a > non-standard way for indirect accessing, so each mixer value isn't > visible in amixer or alsactl. Hello Takashi, Can you tell whether the hdspm driver is able to capture "raw" AES frames, instead of just the PCM payload inside AES frames? Is there any sample code on how to do that? Regards. |