[alsa-devel] SALSA and aplay
Quick questions:
1. Does SALSA provide everything needed by aplay?
2. Is there a version or equivalent of aplay that is a function that can be called from other code rather than the command line? Otherwise I shall hack it so for the purpose of some testing only, but ask to avoid re-inventing (no doubt poorly) something that exists.
BTW SALSA compiled great (thanks Takashi), but with the following warning (which I ignore apart from mentioning here):-
In file included from hcontrol.h:36, from mixer.h:25, from mixer.c:30: hctl_macros.h: In function `snd_hctl_elem_tlv_read': hctl_macros.h:136: warning: `snd_ctl_elem_tlv_read' is deprecated (declared at ctl_macros.h:1134) hctl_macros.h: In function `snd_hctl_elem_tlv_write': hctl_macros.h:142: warning: `snd_ctl_elem_tlv_write' is deprecated (declared at ctl_macros.h:1141) hctl_macros.h: In function `snd_hctl_elem_tlv_command': hctl_macros.h:148: warning: `snd_ctl_elem_tlv_command' is deprecated (declared at ctl_macros.h:1148)
Alan
At Mon, 16 Jul 2007 13:40:23 +0100, Alan Horstmann wrote:
Quick questions:
- Does SALSA provide everything needed by aplay?
Most but not everything. The missing features are: - snd_pcm_mmap_read*/write*() (corresponding to -M option) - device listing (namehint)
- Is there a version or equivalent of aplay that is a function that can be
called from other code rather than the command line? Otherwise I shall hack it so for the purpose of some testing only, but ask to avoid re-inventing (no doubt poorly) something that exists.
How about portable libraries like portaudio or SDL? It's not equivalent with aplay, though.
BTW SALSA compiled great (thanks Takashi), but with the following warning (which I ignore apart from mentioning here):-
In file included from hcontrol.h:36, from mixer.h:25, from mixer.c:30: hctl_macros.h: In function `snd_hctl_elem_tlv_read': hctl_macros.h:136: warning: `snd_ctl_elem_tlv_read' is deprecated (declared at ctl_macros.h:1134) hctl_macros.h: In function `snd_hctl_elem_tlv_write': hctl_macros.h:142: warning: `snd_ctl_elem_tlv_write' is deprecated (declared at ctl_macros.h:1141) hctl_macros.h: In function `snd_hctl_elem_tlv_command': hctl_macros.h:148: warning: `snd_ctl_elem_tlv_command' is deprecated (declared at ctl_macros.h:1148)
You can just ignore them. The unimplemented features are marked as deprecated in the header files. This is intended behavior for making easier to debug unexpected errors. Or, enable TLV support via --enable-tlv configure option.
(Well, I can add another configure option to enable/disable this deprecated flags if it really matters).
Takashi
On Monday 16 July 2007 13:30, you wrote:
At Mon, 16 Jul 2007 13:40:23 +0100,
Alan Horstmann wrote:
Quick questions:
- Does SALSA provide everything needed by aplay?
Most but not everything. The missing features are:
- snd_pcm_mmap_read*/write*() (corresponding to -M option)
- device listing (namehint)
Thanks. Presumably that explains 'undeclared' error for 'snd_devname_t' and 'snd_config' when linking aplay code to salsa. I commented out all applicable bits and it is OK.
Can salsa-lib be installed at the same time as alsa-lib? There seems to be conflicts. For now I have uninstalled and installed alternately.
I have very crudely hacked the aplay code and included it as a function in code to make a simple key-press play a set file. Linking -lasound this seems to work fine. However, linking -lsalsa results in the file playing too fast, but not as much as double.
As my experimental system has ice1712 card, I am having to use a 10 track WAV file S32_LE as I think that is the only format supported, the card working with 24-bits loose fitted in 32-bits. Is that right? Is there still something that alsa-lib is doing to the data that salsa doesn't? My example wav file was recorded using standard aplay, and has meaningful sound just on the first 4 tracks, which appear correctly in pcm out 1-4 (visible in envy24control), at the correct level, just too fast. The included aplay correctly reports
try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Channels 10
when begining to play.
Can you give any pointers to issues to investigate etc or things to consider?
Alan
At Tue, 17 Jul 2007 12:33:36 +0100, Alan Horstmann wrote:
On Monday 16 July 2007 13:30, you wrote:
At Mon, 16 Jul 2007 13:40:23 +0100,
Alan Horstmann wrote:
Quick questions:
- Does SALSA provide everything needed by aplay?
Most but not everything. The missing features are:
- snd_pcm_mmap_read*/write*() (corresponding to -M option)
- device listing (namehint)
Thanks. Presumably that explains 'undeclared' error for 'snd_devname_t' and 'snd_config' when linking aplay code to salsa. I commented out all applicable bits and it is OK.
Can salsa-lib be installed at the same time as alsa-lib? There seems to be conflicts. For now I have uninstalled and installed alternately.
For the runtime environment, yes, but not for the development since both salsa and alsa-lib use the same header file location. But, in principle, it doesn't make much sense to use salsa-lib where alsa-lib is available and needed.
I have very crudely hacked the aplay code and included it as a function in code to make a simple key-press play a set file. Linking -lasound this seems to work fine. However, linking -lsalsa results in the file playing too fast, but not as much as double.
Probably you are playing the samples with the hardware parameters that the hardware doesn't support. alsa-lib has plugin layer which can convert appropriatley on the fly.
As my experimental system has ice1712 card, I am having to use a 10 track WAV file S32_LE as I think that is the only format supported, the card working with 24-bits loose fitted in 32-bits. Is that right?
Yes.
Is there still something that alsa-lib is doing to the data that salsa doesn't? My example wav file was recorded using standard aplay, and has meaningful sound just on the first 4 tracks, which appear correctly in pcm out 1-4 (visible in envy24control), at the correct level, just too fast. The included aplay correctly reports
try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Channels 10
when begining to play.
ice1712 always requires 10-channel interleaved format, regardless how many physical I/O the device has.
Takashi
On Tuesday 17 July 2007 12:58, you wrote:
At Tue, 17 Jul 2007 12:33:36 +0100,
Alan Horstmann wrote:
On Monday 16 July 2007 13:30, you wrote:
I have very crudely hacked the aplay code and included it as a function in code to make a simple key-press play a set file. Linking -lasound this seems to work fine. However, linking -lsalsa results in the file playing too fast, but not as much as double.
Probably you are playing the samples with the hardware parameters that the hardware doesn't support. alsa-lib has plugin layer which can convert appropriatley on the fly.
As my experimental system has ice1712 card, I am having to use a 10 track WAV file S32_LE as I think that is the only format supported, the card working with 24-bits loose fitted in 32-bits.
Are you refering to parameters other than rate, format, channels? I think those are correct now. I have logged snd_pcm_hw_params_dump(params, log); snd_pcm_hw_params_dump(swparams, log); In salsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE hebrew SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (37142 37143) PERIOD_SIZE: 1638 PERIOD_BYTES: 65520 PERIODS: (4 5) BUFFER_TIME: (148594 148595) BUFFER_SIZE: 6553 BUFFER_BYTES: 262120 TICK_TIME: 1000 tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1638 xfer_align: 1638 silence_threshold: 0 silence_size: 0 boundary: 1717829632
In alsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (21333 21334) PERIOD_SIZE: (940 941) PERIOD_BYTES: (37600 37640) PERIODS: (5 7) BUFFER_TIME: (127981 127982) BUFFER_SIZE: 5644 BUFFER_BYTES: 225760 TICK_TIME: 0 start_mode: DATA xrun_mode: STOP tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 940 xfer_align: 940 silence_threshold: 0 silence_size: 0 boundary: 1479540736
Is there significance to 'hebrew' on the format line? The other numbers mean little to me. Sorry to trouble you.
Thanks
Alan
At Tue, 17 Jul 2007 15:38:00 +0100, Alan Horstmann wrote:
On Tuesday 17 July 2007 12:58, you wrote:
At Tue, 17 Jul 2007 12:33:36 +0100,
Alan Horstmann wrote:
On Monday 16 July 2007 13:30, you wrote:
I have very crudely hacked the aplay code and included it as a function in code to make a simple key-press play a set file. Linking -lasound this seems to work fine. However, linking -lsalsa results in the file playing too fast, but not as much as double.
Probably you are playing the samples with the hardware parameters that the hardware doesn't support. alsa-lib has plugin layer which can convert appropriatley on the fly.
As my experimental system has ice1712 card, I am having to use a 10 track WAV file S32_LE as I think that is the only format supported, the card working with 24-bits loose fitted in 32-bits.
Are you refering to parameters other than rate, format, channels? I think those are correct now. I have logged snd_pcm_hw_params_dump(params, log); snd_pcm_hw_params_dump(swparams, log); In salsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE hebrew SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (37142 37143) PERIOD_SIZE: 1638 PERIOD_BYTES: 65520 PERIODS: (4 5) BUFFER_TIME: (148594 148595) BUFFER_SIZE: 6553 BUFFER_BYTES: 262120 TICK_TIME: 1000 tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1638 xfer_align: 1638 silence_threshold: 0 silence_size: 0 boundary: 1717829632
In alsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (21333 21334) PERIOD_SIZE: (940 941) PERIOD_BYTES: (37600 37640) PERIODS: (5 7) BUFFER_TIME: (127981 127982) BUFFER_SIZE: 5644 BUFFER_BYTES: 225760 TICK_TIME: 0 start_mode: DATA xrun_mode: STOP tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 940 xfer_align: 940 silence_threshold: 0 silence_size: 0 boundary: 1479540736
Is there significance to 'hebrew' on the format line? The other numbers mean little to me. Sorry to trouble you.
The string looks strange. Could you try the patch below?
Anyway, I still don't think it's a bug of salsa-lib. Looking the prameters above, it seems you're using "default" PCM, right? If so, try to use "hw" instead. This should make the parameters identical.
Takashi
diff -r 3d5552e4594a src/pcm.c --- a/src/pcm.c Tue Jul 10 14:10:37 2007 +0200 +++ b/src/pcm.c Tue Jul 17 17:04:47 2007 +0200 @@ -284,7 +284,7 @@ const char *_snd_pcm_state_names[] = { STATE(DISCONNECTED), };
-const char *_snd_pcm_access_names[] = { +const char *_snd_pcm_access_names[SND_MASK_MAX + 1] = { ACCESS(MMAP_INTERLEAVED), ACCESS(MMAP_NONINTERLEAVED), ACCESS(MMAP_COMPLEX), @@ -292,7 +292,7 @@ const char *_snd_pcm_access_names[] = { ACCESS(RW_NONINTERLEAVED), };
-const char *_snd_pcm_format_names[] = { +const char *_snd_pcm_format_names[SND_MASK_MAX + 1] = { FORMAT(S8), FORMAT(U8), FORMAT(S16_LE), @@ -333,7 +333,7 @@ const char *_snd_pcm_format_names[] = { FORMAT(U18_3BE), };
-static const char *_snd_pcm_format_aliases[SND_PCM_FORMAT_LAST+1] = { +static const char *_snd_pcm_format_aliases[SND_MASK_MAX + 1] = { FORMAT(S16), FORMAT(U16), FORMAT(S24), @@ -345,7 +345,7 @@ static const char *_snd_pcm_format_alias FORMAT(IEC958_SUBFRAME), };
-const char *_snd_pcm_format_descriptions[] = { +const char *_snd_pcm_format_descriptions[SND_MASK_MAX + 1] = { FORMATD(S8, "Signed 8 bit"), FORMATD(U8, "Unsigned 8 bit"), FORMATD(S16_LE, "Signed 16 bit Little Endian"), @@ -418,11 +418,11 @@ const char *_snd_pcm_type_names[] = { PCMTYPE(EXTPLUG), };
-const char *_snd_pcm_subformat_names[] = { +const char *_snd_pcm_subformat_names[SND_MASK_MAX + 1] = { SUBFORMAT(STD), };
-const char *_snd_pcm_subformat_descriptions[] = { +const char *_snd_pcm_subformat_descriptions[SND_MASK_MAX + 1] = { SUBFORMATD(STD, "Standard"), };
On Tuesday 17 July 2007 16:09, you wrote:
At Tue, 17 Jul 2007 15:38:00 +0100,
Alan Horstmann wrote:
On Tuesday 17 July 2007 12:58, you wrote:
At Tue, 17 Jul 2007 12:33:36 +0100,
Alan Horstmann wrote:
On Monday 16 July 2007 13:30, you wrote:
I have very crudely hacked the aplay code and included it as a function in code to make a simple key-press play a set file. Linking -lasound this seems to work fine. However, linking -lsalsa results in the file playing too fast, but not as much as double.
Probably you are playing the samples with the hardware parameters that the hardware doesn't support. alsa-lib has plugin layer which can convert appropriatley on the fly.
As my experimental system has ice1712 card, I am having to use a 10 track WAV file S32_LE as I think that is the only format supported, the card working with 24-bits loose fitted in 32-bits.
Are you refering to parameters other than rate, format, channels? I think those are correct now. I have logged snd_pcm_hw_params_dump(params, log); snd_pcm_hw_params_dump(swparams, log); In salsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE hebrew SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (37142 37143) PERIOD_SIZE: 1638 PERIOD_BYTES: 65520 PERIODS: (4 5) BUFFER_TIME: (148594 148595) BUFFER_SIZE: 6553 BUFFER_BYTES: 262120 TICK_TIME: 1000 tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1638 xfer_align: 1638 silence_threshold: 0 silence_size: 0 boundary: 1717829632
In alsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (21333 21334) PERIOD_SIZE: (940 941) PERIOD_BYTES: (37600 37640) PERIODS: (5 7) BUFFER_TIME: (127981 127982) BUFFER_SIZE: 5644 BUFFER_BYTES: 225760 TICK_TIME: 0 start_mode: DATA xrun_mode: STOP tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 940 xfer_align: 940 silence_threshold: 0 silence_size: 0 boundary: 1479540736
Is there significance to 'hebrew' on the format line? The other numbers mean little to me. Sorry to trouble you.
The string looks strange. Could you try the patch below?
Patching file pcm.c using Plan A... Hunk #1 succeeded at 284. Hunk #2 succeeded at 292. Hunk #3 succeeded at 333. Hunk #4 succeeded at 345. patch unexpectedly ends in middle of line Hunk #5 succeeded at 418. done
With patch applied, the 'hebrew' is gone!
Anyway, I still don't think it's a bug of salsa-lib. Looking the prameters above, it seems you're using "default" PCM, right? If so, try to use "hw" instead. This should make the parameters identical.
Yes and yes. Using "hw" gives the same wrong speed with -lasound, and standard command-line aplay does also. Evidently I understand even less than I thought. I had expected that with the card hardware set to 44100Hz and locked, that playing a 44100Hz file would be straightforward. Maybe the file is not right. I may have to pause testing for a few days now.
Thanks again
Alan
On Wednesday 18 July 2007 16:01, Alan Horstmann wrote:
Yes and yes. Using "hw" gives the same wrong speed with -lasound, and standard command-line aplay does also. Evidently I understand even less than I thought. I had expected that with the card hardware set to 44100Hz and locked, that playing a 44100Hz file would be straightforward. Maybe the file is not right. I may have to pause testing for a few days now.
Actually, I think I have an idea what is happening, but not why.
aplay -v TMP/try3.wav
Playing WAVE 'TMP/try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Channels 10 Plug PCM: Rate conversion PCM (48000, sformat=S32_LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 44100 exact rate : 44100 (44100/1) msbits : 32 buffer_size : 5644 period_size : 940 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 940 xfer_align : 940 start_threshold : 5640 stop_threshold : 5644 silence_threshold: 0 silence_size : 0 boundary : 1479540736 Slave: Direct Stream Mixing PCM Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6144 period_size : 1024 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 6144 stop_threshold : 6144 silence_threshold: 0 silence_size : 0 boundary : 1610612736 Hardware PCM card 0 'TerraTec DMX6Fire' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6553 period_size : 1024 period_time : 21333 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 1 stop_threshold : 1717829632 silence_threshold: 0 silence_size : 1717829632 boundary : 1717829632
It attempts to set the card to 48000, which fails since I have it locked! When I recorded the file the same was true, so from "default" the file plays back correct although it is in fact wrong, and plays wrong when imported into Audacity. The set-up listed above suggests to me that Alsa is rate converting to 48000 and Mmap'ing to the card. If correct, is that really necessary? I dislike any rate conversions on a serious recording system, and especially hidden ones. Is this a configuration issue that might have changed since, say, 1.0.10 or 1.0.12?
Can I prevent the rate conversion eg in conf file and still have control of format and channel numbers that "hw" prevents? Or is this all down to the way aplay does things?
Alan
At Wed, 18 Jul 2007 17:20:29 +0100, Alan Horstmann wrote:
On Wednesday 18 July 2007 16:01, Alan Horstmann wrote:
Yes and yes. Using "hw" gives the same wrong speed with -lasound, and standard command-line aplay does also. Evidently I understand even less than I thought. I had expected that with the card hardware set to 44100Hz and locked, that playing a 44100Hz file would be straightforward. Maybe the file is not right. I may have to pause testing for a few days now.
Actually, I think I have an idea what is happening, but not why.
aplay -v TMP/try3.wav
Playing WAVE 'TMP/try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Channels 10 Plug PCM: Rate conversion PCM (48000, sformat=S32_LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 44100 exact rate : 44100 (44100/1) msbits : 32 buffer_size : 5644 period_size : 940 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 940 xfer_align : 940 start_threshold : 5640 stop_threshold : 5644 silence_threshold: 0 silence_size : 0 boundary : 1479540736 Slave: Direct Stream Mixing PCM Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6144 period_size : 1024 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 6144 stop_threshold : 6144 silence_threshold: 0 silence_size : 0 boundary : 1610612736 Hardware PCM card 0 'TerraTec DMX6Fire' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6553 period_size : 1024 period_time : 21333 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 1 stop_threshold : 1717829632 silence_threshold: 0 silence_size : 1717829632 boundary : 1717829632
It attempts to set the card to 48000, which fails since I have it locked! When I recorded the file the same was true, so from "default" the file plays back correct although it is in fact wrong, and plays wrong when imported into Audacity. The set-up listed above suggests to me that Alsa is rate converting to 48000 and Mmap'ing to the card. If correct, is that really necessary? I dislike any rate conversions on a serious recording system, and especially hidden ones. Is this a configuration issue that might have changed since, say, 1.0.10 or 1.0.12?
The 48k-fixed rate is due to dmix plugin. It requires a fixed sample rate for all apps. In theory, it may accept multiple rates, but the feature is not implemented yet.
You can change the default rate by overriding defaults.pcm.dmix.rate config item, e.g. define the below in ~/.asoundrc:
defaults.pcm.dmix.rate 44100
Takashi
On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote:
At Wed, 18 Jul 2007 17:20:29 +0100, Alan Horstmann wrote:
On Wednesday 18 July 2007 16:01, Alan Horstmann wrote:
Yes and yes. Using "hw" gives the same wrong speed with -lasound, and standard command-line aplay does also. Evidently I understand even less than I thought. I had expected that with the card hardware set to 44100Hz and locked, that playing a 44100Hz file would be straightforward. Maybe the file is not right. I may have to pause testing for a few days now.
Actually, I think I have an idea what is happening, but not why.
aplay -v TMP/try3.wav
Playing WAVE 'TMP/try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Channels 10 Plug PCM: Rate conversion PCM (48000, sformat=S32_LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 44100 exact rate : 44100 (44100/1) msbits : 32 buffer_size : 5644 period_size : 940 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 940 xfer_align : 940 start_threshold : 5640 stop_threshold : 5644 silence_threshold: 0 silence_size : 0 boundary : 1479540736 Slave: Direct Stream Mixing PCM Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6144 period_size : 1024 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 6144 stop_threshold : 6144 silence_threshold: 0 silence_size : 0 boundary : 1610612736 Hardware PCM card 0 'TerraTec DMX6Fire' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6553 period_size : 1024 period_time : 21333 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 1 stop_threshold : 1717829632 silence_threshold: 0 silence_size : 1717829632 boundary : 1717829632
It attempts to set the card to 48000, which fails since I have it locked! When I recorded the file the same was true, so from "default" the file plays back correct although it is in fact wrong, and plays wrong when imported into Audacity. The set-up listed above suggests to me that Alsa is rate converting to 48000 and Mmap'ing to the card. If correct, is that really necessary? I dislike any rate conversions on a serious recording system, and especially hidden ones. Is this a configuration issue that might have changed since, say, 1.0.10 or 1.0.12?
The 48k-fixed rate is due to dmix plugin. It requires a fixed sample rate for all apps. In theory, it may accept multiple rates, but the feature is not implemented yet.
You can change the default rate by overriding defaults.pcm.dmix.rate config item, e.g. define the below in ~/.asoundrc:
defaults.pcm.dmix.rate 44100
Wouldn't it be better to specify hw:0 (or whatever card you are using) in this case? With this type of hardware I'd rather make sure that dmix isn't used at all (I assume that dmix is now the default instead of hw:0).
John
At Thu, 19 Jul 2007 15:24:40 +0100, John Rigg wrote:
On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote:
At Wed, 18 Jul 2007 17:20:29 +0100, Alan Horstmann wrote:
On Wednesday 18 July 2007 16:01, Alan Horstmann wrote:
Yes and yes. Using "hw" gives the same wrong speed with -lasound, and standard command-line aplay does also. Evidently I understand even less than I thought. I had expected that with the card hardware set to 44100Hz and locked, that playing a 44100Hz file would be straightforward. Maybe the file is not right. I may have to pause testing for a few days now.
Actually, I think I have an idea what is happening, but not why.
aplay -v TMP/try3.wav
Playing WAVE 'TMP/try3.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Channels 10 Plug PCM: Rate conversion PCM (48000, sformat=S32_LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 44100 exact rate : 44100 (44100/1) msbits : 32 buffer_size : 5644 period_size : 940 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 940 xfer_align : 940 start_threshold : 5640 stop_threshold : 5644 silence_threshold: 0 silence_size : 0 boundary : 1479540736 Slave: Direct Stream Mixing PCM Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6144 period_size : 1024 period_time : 21333 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 6144 stop_threshold : 6144 silence_threshold: 0 silence_size : 0 boundary : 1610612736 Hardware PCM card 0 'TerraTec DMX6Fire' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 10 rate : 48000 exact rate : 48000 (48000/1) msbits : 24 buffer_size : 6553 period_size : 1024 period_time : 21333 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 1 stop_threshold : 1717829632 silence_threshold: 0 silence_size : 1717829632 boundary : 1717829632
It attempts to set the card to 48000, which fails since I have it locked! When I recorded the file the same was true, so from "default" the file plays back correct although it is in fact wrong, and plays wrong when imported into Audacity. The set-up listed above suggests to me that Alsa is rate converting to 48000 and Mmap'ing to the card. If correct, is that really necessary? I dislike any rate conversions on a serious recording system, and especially hidden ones. Is this a configuration issue that might have changed since, say, 1.0.10 or 1.0.12?
The 48k-fixed rate is due to dmix plugin. It requires a fixed sample rate for all apps. In theory, it may accept multiple rates, but the feature is not implemented yet.
You can change the default rate by overriding defaults.pcm.dmix.rate config item, e.g. define the below in ~/.asoundrc:
defaults.pcm.dmix.rate 44100
Wouldn't it be better to specify hw:0 (or whatever card you are using) in this case? With this type of hardware I'd rather make sure that dmix isn't used at all (I assume that dmix is now the default instead of hw:0).
Well, you can claim that because you don't get bug reports or rants ;)
The only reason that plug+dmix is used is that it can handle most cases without hitches. It works as it is. That's all above other reasons.
Takashi
On Thu, Jul 19, 2007 at 04:27:29PM +0200, Takashi Iwai wrote:
At Thu, 19 Jul 2007 15:24:40 +0100, John Rigg wrote:
Wouldn't it be better to specify hw:0 (or whatever card you are using) in this case? With this type of hardware I'd rather make sure that dmix isn't used at all (I assume that dmix is now the default instead of hw:0).
Well, you can claim that because you don't get bug reports or rants ;)
:-) I wasn't criticising the decision to make dmix the default, just suggesting that Alan and other users of pro and semi-pro hardware specify on the command line which device they want apps to use.
The only reason that plug+dmix is used is that it can handle most cases without hitches. It works as it is. That's all above other reasons.
I understand entirely.
John
< Previously subject: Re: SALSA and aplay >
On Thursday 19 July 2007 15:24, you wrote:
On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote:
At Wed, 18 Jul 2007 17:20:29 +0100,
Alan Horstmann wrote:
Actually, I think I have an idea what is happening, but not why.
It attempts to set the card to 48000, which fails since I have it locked! When I recorded the file the same was true, so from "default" the file plays back correct although it is in fact wrong, and plays wrong when imported into Audacity. The set-up listed above suggests to me that Alsa is rate converting to 48000 and Mmap'ing to the card. If correct, is that really necessary? I dislike any rate conversions on a serious recording system, and especially hidden ones. Is this a configuration issue that might have changed since, say, 1.0.10 or 1.0.12?
The 48k-fixed rate is due to dmix plugin. It requires a fixed sample rate for all apps. In theory, it may accept multiple rates, but the feature is not implemented yet.
You can change the default rate by overriding defaults.pcm.dmix.rate config item, e.g. define the below in ~/.asoundrc:
defaults.pcm.dmix.rate 44100
Wouldn't it be better to specify hw:0 (or whatever card you are using) in this case? With this type of hardware I'd rather make sure that dmix isn't used at all (I assume that dmix is now the default instead of hw:0).
I have less concern with dmix than the hidden rate conversion, but would happily loose both. Using "hw" forces use of 12 capture and 10 playback channels in this case, doesn't it? So I need some plugin to play 2 channels?
There are 2 issues for me:
1. With the cards rate state = 'locked' alsa (not sure what bit of it) was unable to set the desired clock rate, yet did not report an error. Data was then eg captured from the card as if it was running at 48K, but actually it remained at 44.1K. Thus the recorded data was wrong.
snd_pcm_hw_params_set_rate_near(..)
did not report error because it was asking for 44.1K; somewhere else the configuration decided 48K was better, but did not highlight that the card refused to change setting. Surely this should class as a bug.
Since the inverse error happens on capture, it is not immediately obvious that there is a problem with the recording, so important recordings could be completely messed up.
2. These ice1712-based pro/semi-pro hardware systems should IMO NEVER perform secret rate conversion. They are designed for readers of 'Sound on Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if their Windows drivers quietly set the card to a different rate to that requested and rate converted the data! Especially so on a capture stream. Remember the cards are 24-bit 96KHz capable and approach 100dB signal-to-noise ratio.
Whilst there may be circumstances in which material recorded at different rates has to be used in the same project, it is only converted once, in full knowledge.
Can't dmix be configured to run at whatever rate is set on the card, or the requested rate, rather than attempt to overule both of them?
Alan
On Fri, 20 Jul 2007 13:33:38 +0100 Alan Horstmann gineera@aspect135.co.uk wrote:
[snip]
I have less concern with dmix than the hidden rate conversion, but would happily loose both. Using "hw" forces use of 12 capture and 10 playback channels in this case, doesn't it? So I need some plugin to play 2 channels?
There are 2 issues for me:
- With the cards rate state = 'locked' alsa (not sure what bit of
it) was unable to set the desired clock rate, yet did not report an error. Data was then eg captured from the card as if it was running at 48K, but actually it remained at 44.1K. Thus the recorded data was wrong.
snd_pcm_hw_params_set_rate_near(..)
did not report error because it was asking for 44.1K; somewhere else the configuration decided 48K was better, but did not highlight that the card refused to change setting. Surely this should class as a bug.
Since the inverse error happens on capture, it is not immediately obvious that there is a problem with the recording, so important recordings could be completely messed up.
- These ice1712-based pro/semi-pro hardware systems should IMO NEVER
perform secret rate conversion. They are designed for readers of 'Sound on Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if their Windows drivers quietly set the card to a different rate to that requested and rate converted the data! Especially so on a capture stream. Remember the cards are 24-bit 96KHz capable and approach 100dB signal-to-noise ratio.
Whilst there may be circumstances in which material recorded at different rates has to be used in the same project, it is only converted once, in full knowledge.
Can't dmix be configured to run at whatever rate is set on the card, or the requested rate, rather than attempt to overule both of them?
Alan
For what it's worth, I agree with Alan here. Any sound library with aspirations to professional use can't have hidden conversions and silent corrections going on.
However, I also agree with Takashi that for the average user having the dmix plugin as a default is a very good thing.
So, would it be possible to have an api call in the interface to disable the dmix plugin for any instance of alsa. For example, I call the interface to open the default sound device. Another call gets me the hardware associated with the default device. I then tell the interface to bypass any filters or plugins, basically giving access to the hw interface for whichever card is default for this stream only.
Maybe this already exists. If it does, could you point me in the right direction (which function). If not, where would it be best implemented (which source file)? I don't know that I could or will write it, but I would like to have a look at how difficult it would be.
Thanks. stan
On Sun, 22 Jul 2007, stan wrote:
On Fri, 20 Jul 2007 13:33:38 +0100 Alan Horstmann gineera@aspect135.co.uk wrote:
[snip]
I have less concern with dmix than the hidden rate conversion, but would happily loose both. Using "hw" forces use of 12 capture and 10 playback channels in this case, doesn't it? So I need some plugin to play 2 channels?
There are 2 issues for me:
- With the cards rate state = 'locked' alsa (not sure what bit of
it) was unable to set the desired clock rate, yet did not report an error. Data was then eg captured from the card as if it was running at 48K, but actually it remained at 44.1K. Thus the recorded data was wrong.
snd_pcm_hw_params_set_rate_near(..)
did not report error because it was asking for 44.1K; somewhere else the configuration decided 48K was better, but did not highlight that the card refused to change setting. Surely this should class as a bug.
Since the inverse error happens on capture, it is not immediately obvious that there is a problem with the recording, so important recordings could be completely messed up.
- These ice1712-based pro/semi-pro hardware systems should IMO NEVER
perform secret rate conversion. They are designed for readers of 'Sound on Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if their Windows drivers quietly set the card to a different rate to that requested and rate converted the data! Especially so on a capture stream. Remember the cards are 24-bit 96KHz capable and approach 100dB signal-to-noise ratio.
Whilst there may be circumstances in which material recorded at different rates has to be used in the same project, it is only converted once, in full knowledge.
Can't dmix be configured to run at whatever rate is set on the card, or the requested rate, rather than attempt to overule both of them?
Alan
For what it's worth, I agree with Alan here. Any sound library with aspirations to professional use can't have hidden conversions and silent corrections going on.
However, I also agree with Takashi that for the average user having the dmix plugin as a default is a very good thing.
So, would it be possible to have an api call in the interface to disable the dmix plugin for any instance of alsa. For example, I call the interface to open the default sound device. Another call gets me the hardware associated with the default device. I then tell the interface to bypass any filters or plugins, basically giving access to the hw interface for whichever card is default for this stream only.
Maybe this already exists. If it does, could you point me in the right direction (which function). If not, where would it be best implemented (which source file)? I don't know that I could or will write it, but I would like to have a look at how difficult it would be.
The library is intended to hide all these details for applications. You can disable sample conversion on demand (snd_pcm_hw_params_set_rate_resample) to use own better resampler.
Note that conversions are not used when application asks for parameters which hw already supports. Of course, dmix is different thing, but the definition of default device is that it should be common for most applications. Other applications have possibility to choose another device / abstraction. These applications can determine card number and device/subdevice numbers via snd_pcm_info_get_card,device,subdevice functions and try to open "raw" hw:card,device,subdevice PCM devices.
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
On Mon, 23 Jul 2007 10:15:07 +0200 (CEST) Jaroslav Kysela perex@suse.cz wrote:
On Sun, 22 Jul 2007, stan wrote:
On Fri, 20 Jul 2007 13:33:38 +0100 Alan Horstmann gineera@aspect135.co.uk wrote:
[snip]
I have less concern with dmix than the hidden rate conversion, but would happily loose both. Using "hw" forces use of 12 capture and 10 playback channels in this case, doesn't it? So I need some plugin to play 2 channels?
There are 2 issues for me:
- With the cards rate state = 'locked' alsa (not sure what bit of
it) was unable to set the desired clock rate, yet did not report an error. Data was then eg captured from the card as if it was running at 48K, but actually it remained at 44.1K. Thus the recorded data was wrong.
snd_pcm_hw_params_set_rate_near(..)
did not report error because it was asking for 44.1K; somewhere else the configuration decided 48K was better, but did not highlight that the card refused to change setting. Surely this should class as a bug.
Since the inverse error happens on capture, it is not immediately obvious that there is a problem with the recording, so important recordings could be completely messed up.
- These ice1712-based pro/semi-pro hardware systems should IMO
NEVER perform secret rate conversion. They are designed for readers of 'Sound on Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if their Windows drivers quietly set the card to a different rate to that requested and rate converted the data! Especially so on a capture stream. Remember the cards are 24-bit 96KHz capable and approach 100dB signal-to-noise ratio.
Whilst there may be circumstances in which material recorded at different rates has to be used in the same project, it is only converted once, in full knowledge.
Can't dmix be configured to run at whatever rate is set on the card, or the requested rate, rather than attempt to overule both of them?
Alan
For what it's worth, I agree with Alan here. Any sound library with aspirations to professional use can't have hidden conversions and silent corrections going on.
However, I also agree with Takashi that for the average user having the dmix plugin as a default is a very good thing.
So, would it be possible to have an api call in the interface to disable the dmix plugin for any instance of alsa. For example, I call the interface to open the default sound device. Another call gets me the hardware associated with the default device. I then tell the interface to bypass any filters or plugins, basically giving access to the hw interface for whichever card is default for this stream only.
Maybe this already exists. If it does, could you point me in the right direction (which function). If not, where would it be best implemented (which source file)? I don't know that I could or will write it, but I would like to have a look at how difficult it would be.
The library is intended to hide all these details for applications. You can disable sample conversion on demand (snd_pcm_hw_params_set_rate_resample) to use own better resampler.
Note that conversions are not used when application asks for parameters which hw already supports. Of course, dmix is different thing, but the definition of default device is that it should be common for most applications. Other applications have possibility to choose another device / abstraction. These applications can determine card number and device/subdevice numbers via snd_pcm_info_get_card,device,subdevice functions and try to open "raw" hw:card,device,subdevice PCM devices.
Thank you Jaroslav,
That's what I was looking for.
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
On Friday 20 July 2007 13:33, Alan Horstmann wrote:
< Previously subject: Re: SALSA and aplay >
On Thursday 19 July 2007 15:24, you wrote:
On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote:
At Wed, 18 Jul 2007 17:20:29 +0100,
The 48k-fixed rate is due to dmix plugin. It requires a fixed sample rate for all apps. In theory, it may accept multiple rates, but the feature is not implemented yet.
You can change the default rate by overriding defaults.pcm.dmix.rate config item, e.g. define the below in ~/.asoundrc:
defaults.pcm.dmix.rate 44100
Wouldn't it be better to specify hw:0 (or whatever card you are using) in this case? With this type of hardware I'd rather make sure that dmix isn't used at all (I assume that dmix is now the default instead of hw:0).
I have less concern with dmix than the hidden rate conversion, but would happily loose both. Using "hw" forces use of 12 capture and 10 playback channels in this case, doesn't it? So I need some plugin to play 2 channels?
There are 2 issues for me:
- With the cards rate state = 'locked' alsa (not sure what bit of it) was
unable to set the desired clock rate, yet did not report an error. Data was then eg captured from the card as if it was running at 48K, but actually it remained at 44.1K. Thus the recorded data was wrong.
snd_pcm_hw_params_set_rate_near(..)
did not report error because it was asking for 44.1K; somewhere else the configuration decided 48K was better, but did not highlight that the card refused to change setting. Surely this should class as a bug.
Since the inverse error happens on capture, it is not immediately obvious that there is a problem with the recording, so important recordings could be completely messed up.
- These ice1712-based pro/semi-pro hardware systems should IMO NEVER
perform secret rate conversion. They are designed for readers of 'Sound on Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if their Windows drivers quietly set the card to a different rate to that requested and rate converted the data! Especially so on a capture stream. Remember the cards are 24-bit 96KHz capable and approach 100dB signal-to-noise ratio.
Whilst there may be circumstances in which material recorded at different rates has to be used in the same project, it is only converted once, in full knowledge.
Can't dmix be configured to run at whatever rate is set on the card, or the requested rate, rather than attempt to overule both of them?
Takashi,
Was this missed or ignored?!!
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Thanks
Alan
On 7/27/07, Alan Horstmann gineera@aspect135.co.uk wrote:
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Simply open the hw device rather than the default, dmix, or plughw device.
Lee
On Fri, 27 Jul 2007 11:59:53 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 7/27/07, Alan Horstmann gineera@aspect135.co.uk wrote:
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Simply open the hw device rather than the default, dmix, or plughw device.
Lee
Lee,
Are you saying that plughw *does* do hidden conversion? I thought its definition was equivalent to
newplug { type plug slave { pcm "hw:0,0" } }
Is this doing conversion?
On 7/27/07, stan stanl@cox.net wrote:
On Fri, 27 Jul 2007 11:59:53 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 7/27/07, Alan Horstmann gineera@aspect135.co.uk wrote:
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Simply open the hw device rather than the default, dmix, or plughw device.
Lee
Lee,
Are you saying that plughw *does* do hidden conversion? I thought its definition was equivalent to
newplug { type plug slave { pcm "hw:0,0" } }
It's not "hidden" conversion, by using the plughw device you are explicitly asking ALSA to convert the PCM stream to a format the hardware supports.
Lee
On Fri, 27 Jul 2007 15:38:28 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 7/27/07, stan stanl@cox.net wrote:
On Fri, 27 Jul 2007 11:59:53 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 7/27/07, Alan Horstmann gineera@aspect135.co.uk wrote:
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Simply open the hw device rather than the default, dmix, or plughw device.
Lee
Lee,
Are you saying that plughw *does* do hidden conversion? I thought its definition was equivalent to
newplug { type plug slave { pcm "hw:0,0" } }
It's not "hidden" conversion, by using the plughw device you are explicitly asking ALSA to convert the PCM stream to a format the hardware supports.
Lee
Thanks Lee. I didn't understand that. Does that mean that I can't use a call like
err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_FLOAT64);
to a device opened to the hw plug if the native format is S32_LE? I'm guessing that I have to know (or read) the internal format of the card and send it data only in that format. I end up doing the conversion instead of alsa unless I happen to hit a card that has the same internal representation as I'm using.
And will plughw skip rate conversion if it is a rate the hardware natively supports? So I could send a buffer of doubles to alsa and it would convert it to the cards native internal representation, but skip the rate conversion if it is a hardware supported one.
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate resampling can introduce throughput issues and inaccuracies in the sound stream.
On Fri, 27 Jul 2007, stan wrote:
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate
Not really. If application knows all things, the final code might be much more optimized. Alsa-lib has all plugins universal (thus mostly unoptimized). For example - attenuation + sample conversion can be implemented together, but alsa-lib has two plugins - it means two iteration over same data.
resampling can introduce throughput issues and inaccuracies in the sound stream.
I answered this numerous times on this list. We have a function to notify the plugins that resampling should be avoided - it's snd_pcm_hw_params_set_rate_resample().
hw:x,y,z - native device without any conversions plughw:x,y,z - device trying to do all conversions for applications default - default device with all conversions (mostly pointing to plughw:x,y,z)
And yes, plugin doing all conversions is named "plug". So anywhere where "plug" plugin is used, other plugins - including the rate plugin - can be dynamically inserted to satisfy application requirements.
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
On Fri, 27 Jul 2007 22:16:44 +0200 (CEST) Jaroslav Kysela perex@suse.cz wrote:
On Fri, 27 Jul 2007, stan wrote:
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate
Not really. If application knows all things, the final code might be much more optimized. Alsa-lib has all plugins universal (thus mostly unoptimized). For example - attenuation + sample conversion can be implemented together, but alsa-lib has two plugins - it means two iteration over same data.
I'll have to do some thinking about the tradeoffs of coding time against throughput optimization.
resampling can introduce throughput issues and inaccuracies in the sound stream.
I answered this numerous times on this list. We have a function to notify the plugins that resampling should be avoided - it's snd_pcm_hw_params_set_rate_resample().
Sorry for the repeat. Once I see it, I remember seeing it before.
hw:x,y,z - native device without any conversions plughw:x,y,z - device trying to do all conversions for applications default - default device with all conversions (mostly pointing to plughw:x,y,z)
And yes, plugin doing all conversions is named "plug". So anywhere where "plug" plugin is used, other plugins - including the rate plugin - can be dynamically inserted to satisfy application requirements.
Jaroslav
Thanks for your answers Jaroslav, that clears it up for me.
On Friday 27 July 2007 21:16, Jaroslav Kysela wrote:
On Fri, 27 Jul 2007, stan wrote:
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate
I answered this numerous times on this list. We have a function to notify the plugins that resampling should be avoided - it's snd_pcm_hw_params_set_rate_resample().
Can this function be built into an ALSA configuration file in some way, or can it only be called from an app?
Alan
Alan Horstmann wrote:
On Friday 27 July 2007 21:16, Jaroslav Kysela wrote:
On Fri, 27 Jul 2007, stan wrote:
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate
I answered this numerous times on this list. We have a function to notify the plugins that resampling should be avoided - it's snd_pcm_hw_params_set_rate_resample().
Can this function be built into an ALSA configuration file in some way, or can it only be called from an app?
Alan
It is only really sensible to have the app do the call, and not a config file. Reason being, if the app does the call, it must also be able to handle the resampling itself. If the config file did it, the app might not be able to do the resampling itself and therefore fail to play anything. Generally, the app is the best place to do the resampling, as it can handle the quality issues better. The resampler in ALSA is only really there to let other apps that don't do resampling limp along ok.
James
At Fri, 03 Aug 2007 15:29:48 +0100, James Courtier-Dutton wrote:
Alan Horstmann wrote:
On Friday 27 July 2007 21:16, Jaroslav Kysela wrote:
On Fri, 27 Jul 2007, stan wrote:
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate
I answered this numerous times on this list. We have a function to notify the plugins that resampling should be avoided - it's snd_pcm_hw_params_set_rate_resample().
Can this function be built into an ALSA configuration file in some way, or can it only be called from an app?
Alan
It is only really sensible to have the app do the call, and not a config file. Reason being, if the app does the call, it must also be able to handle the resampling itself. If the config file did it, the app might not be able to do the resampling itself and therefore fail to play anything. Generally, the app is the best place to do the resampling, as it can handle the quality issues better. The resampler in ALSA is only really there to let other apps that don't do resampling limp along ok.
Well, it's basically a user's choice whether he really wants only a fixed certain samplerate over all apps or not. If he wants, he can set up his own default PCM, of course.
As a hint, the plug plugin can have "slave.rate unchanged" parameter. For example,
pcm.mypcm { type plug slave.pcm "myownhw" slave.rate unchanged }
would wrap the slave PCM "myownhw" with plug layer but the automatic rate conversion is suppressed there. This allow, however, automatic conversions of other parameters such as channels and format.
Takashi
On Friday 03 August 2007 16:11, you wrote:
At Fri, 03 Aug 2007 15:29:48 +0100,
James Courtier-Dutton wrote:
Alan Horstmann wrote:
On Friday 27 July 2007 21:16, Jaroslav Kysela wrote:
On Fri, 27 Jul 2007, stan wrote:
I really want to avoid rate resampling if I can, while format conversion has to occur somewhere in order to match the hardware in most cases. I assume that any format conversion alsa does is at least as good as one I would do myself. While the rate
I answered this numerous times on this list. We have a function to notify the plugins that resampling should be avoided - it's snd_pcm_hw_params_set_rate_resample().
Can this function be built into an ALSA configuration file in some way, or can it only be called from an app?
Alan
It is only really sensible to have the app do the call, and not a config file. Reason being, if the app does the call, it must also be able to handle the resampling itself. If the config file did it, the app might not be able to do the resampling itself and therefore fail to play anything. Generally, the app is the best place to do the resampling, as it can handle the quality issues better. The resampler in ALSA is only really there to let other apps that don't do resampling limp along ok.
Well, it's basically a user's choice whether he really wants only a fixed certain samplerate over all apps or not. If he wants, he can set up his own default PCM, of course.
As a hint, the plug plugin can have "slave.rate unchanged" parameter. For example,
pcm.mypcm { type plug slave.pcm "myownhw" slave.rate unchanged }
would wrap the slave PCM "myownhw" with plug layer but the automatic rate conversion is suppressed there. This allow, however, automatic conversions of other parameters such as channels and format.
Thanks! I'll experiment with this when back from hols.
Alan
On Fri, 27 Jul 2007 11:59:53 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 7/27/07, Alan Horstmann gineera@aspect135.co.uk wrote:
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Simply open the hw device rather than the default, dmix, or plughw device.
Lee
When I use the following call with device_to_use == "plughw:0,0" it works just fine. When I try to use device_to_use == "hw:0,0" it gives a segmentation fault. Is there a special initialization needed to use the hw plug?
err = snd_pcm_open (&alsa_dev, device_to_use, SND_PCM_STREAM_PLAYBACK, 0);
Thank you for any clarification.
On Fri, 27 Jul 2007 10:53:16 -0700 stan stanl@cox.net wrote:
On Fri, 27 Jul 2007 11:59:53 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 7/27/07, Alan Horstmann gineera@aspect135.co.uk wrote:
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
Simply open the hw device rather than the default, dmix, or plughw device.
Lee
When I use the following call with device_to_use == "plughw:0,0" it works just fine. When I try to use device_to_use == "hw:0,0" it gives a segmentation fault. Is there a special initialization needed to use the hw plug?
err = snd_pcm_open (&alsa_dev, device_to_use, SND_PCM_STREAM_PLAYBACK, 0);
I see from this alsa-project doc page http://alsa-project.org/alsa-doc/alsa-lib/pcm__hw_8c.html#d0275f35954d3681fd... that there are special functions for this : snd_pcm_hw_open or _snd_pcm_hw_open.
At Fri, 27 Jul 2007 17:20:41 +0100, Alan Horstmann wrote:
On Friday 20 July 2007 13:33, Alan Horstmann wrote:
< Previously subject: Re: SALSA and aplay >
On Thursday 19 July 2007 15:24, you wrote:
On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote:
At Wed, 18 Jul 2007 17:20:29 +0100,
The 48k-fixed rate is due to dmix plugin. It requires a fixed sample rate for all apps. In theory, it may accept multiple rates, but the feature is not implemented yet.
You can change the default rate by overriding defaults.pcm.dmix.rate config item, e.g. define the below in ~/.asoundrc:
defaults.pcm.dmix.rate 44100
Wouldn't it be better to specify hw:0 (or whatever card you are using) in this case? With this type of hardware I'd rather make sure that dmix isn't used at all (I assume that dmix is now the default instead of hw:0).
I have less concern with dmix than the hidden rate conversion, but would happily loose both. Using "hw" forces use of 12 capture and 10 playback channels in this case, doesn't it? So I need some plugin to play 2 channels?
Yes. The route plugin.
There are 2 issues for me:
- With the cards rate state = 'locked' alsa (not sure what bit of it) was
unable to set the desired clock rate, yet did not report an error. Data was then eg captured from the card as if it was running at 48K, but actually it remained at 44.1K. Thus the recorded data was wrong.
snd_pcm_hw_params_set_rate_near(..)
did not report error because it was asking for 44.1K; somewhere else the configuration decided 48K was better, but did not highlight that the card refused to change setting. Surely this should class as a bug.
Since the inverse error happens on capture, it is not immediately obvious that there is a problem with the recording, so important recordings could be completely messed up.
This is rather a driver problem (or maybe the configuration issue that doesn't reset the locked rate to a proper value). Should be fixed, maybe later.
- These ice1712-based pro/semi-pro hardware systems should IMO NEVER
perform secret rate conversion. They are designed for readers of 'Sound on Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if their Windows drivers quietly set the card to a different rate to that requested and rate converted the data! Especially so on a capture stream. Remember the cards are 24-bit 96KHz capable and approach 100dB signal-to-noise ratio.
The "default" PCM is the laziest setting, which accepts the things as much as possible. That is, the default PCM is definitely _not_ for "pro" guys. And, the real pro would use JACK with hw PCM, so this shouldn't matter :)
Whilst there may be circumstances in which material recorded at different rates has to be used in the same project, it is only converted once, in full knowledge.
Can't dmix be configured to run at whatever rate is set on the card, or the requested rate, rather than attempt to overule both of them?
Takashi,
Was this missed or ignored?!!
Sorry, your post was burried in flood of incoming mails over (literally) thousands mails per day...
Could you give pointers as to how to modify Alsa configuration so that rate conversion can never happen, as I would prefer to have an error accessing the sound card rather than unknown conversion, which in my use should never be neccesary anyway.
If any implicit conversion does matter, use hw PCM. That's exactly what is designed for. Any other convenience with plugins is your choice.
We provide the laziest setting as the default, and this won't be changed unless people will stop bugging about non-working apps :)
Takashi
At Wed, 18 Jul 2007 16:01:11 +0100, Alan Horstmann wrote:
On Tuesday 17 July 2007 16:09, you wrote:
At Tue, 17 Jul 2007 15:38:00 +0100,
Alan Horstmann wrote:
On Tuesday 17 July 2007 12:58, you wrote:
At Tue, 17 Jul 2007 12:33:36 +0100,
Alan Horstmann wrote:
On Monday 16 July 2007 13:30, you wrote:
I have very crudely hacked the aplay code and included it as a function in code to make a simple key-press play a set file. Linking -lasound this seems to work fine. However, linking -lsalsa results in the file playing too fast, but not as much as double.
Probably you are playing the samples with the hardware parameters that the hardware doesn't support. alsa-lib has plugin layer which can convert appropriatley on the fly.
As my experimental system has ice1712 card, I am having to use a 10 track WAV file S32_LE as I think that is the only format supported, the card working with 24-bits loose fitted in 32-bits.
Are you refering to parameters other than rate, format, channels? I think those are correct now. I have logged snd_pcm_hw_params_dump(params, log); snd_pcm_hw_params_dump(swparams, log); In salsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE hebrew SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (37142 37143) PERIOD_SIZE: 1638 PERIOD_BYTES: 65520 PERIODS: (4 5) BUFFER_TIME: (148594 148595) BUFFER_SIZE: 6553 BUFFER_BYTES: 262120 TICK_TIME: 1000 tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1638 xfer_align: 1638 silence_threshold: 0 silence_size: 0 boundary: 1717829632
In alsa:- ACCESS: RW_INTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 320 CHANNELS: 10 RATE: 44100 PERIOD_TIME: (21333 21334) PERIOD_SIZE: (940 941) PERIOD_BYTES: (37600 37640) PERIODS: (5 7) BUFFER_TIME: (127981 127982) BUFFER_SIZE: 5644 BUFFER_BYTES: 225760 TICK_TIME: 0 start_mode: DATA xrun_mode: STOP tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 940 xfer_align: 940 silence_threshold: 0 silence_size: 0 boundary: 1479540736
Is there significance to 'hebrew' on the format line? The other numbers mean little to me. Sorry to trouble you.
The string looks strange. Could you try the patch below?
Patching file pcm.c using Plan A... Hunk #1 succeeded at 284. Hunk #2 succeeded at 292. Hunk #3 succeeded at 333. Hunk #4 succeeded at 345. patch unexpectedly ends in middle of line Hunk #5 succeeded at 418. done
With patch applied, the 'hebrew' is gone!
Thanks for confirmation. The patch was included in 0.0.8 release.
Takashi
On Thursday 19 July 2007 10:30, you wrote:
At Wed, 18 Jul 2007 16:01:11 +0100,
Alan Horstmann wrote:
Patching file pcm.c using Plan A... Hunk #1 succeeded at 284. Hunk #2 succeeded at 292. Hunk #3 succeeded at 333. Hunk #4 succeeded at 345. patch unexpectedly ends in middle of line Hunk #5 succeeded at 418. done
With patch applied, the 'hebrew' is gone!
Thanks for confirmation. The patch was included in 0.0.8 release.
OK. Salsa is performing the same as asound using "hw", except one other perhaps trivial thing I have noticed. The aplay code does err = snd_output_stdio_attach(&log, stderr, 0); and prints things snd_pcm_hw_params_dump(params, log); finishing with snd_output_close(log) In alsa-lib, the third parameter of .._attach is used to set 'close', and being 0, means stderr is not closed. However, with salsa the file is always closed at the end. I am using the aplay code as a function, and on the 2nd call, there are non of the print items. Preventing this close in salsa or the aplay code does remove the problem. Is this intended trimming of functionality for min size?
Ultimately though, I can live with this.
I will continue the configuration discussions with a different title (since not salsa-related).
Alan
At Fri, 20 Jul 2007 12:57:07 +0100, Alan Horstmann wrote:
On Thursday 19 July 2007 10:30, you wrote:
At Wed, 18 Jul 2007 16:01:11 +0100,
Alan Horstmann wrote:
Patching file pcm.c using Plan A... Hunk #1 succeeded at 284. Hunk #2 succeeded at 292. Hunk #3 succeeded at 333. Hunk #4 succeeded at 345. patch unexpectedly ends in middle of line Hunk #5 succeeded at 418. done
With patch applied, the 'hebrew' is gone!
Thanks for confirmation. The patch was included in 0.0.8 release.
OK. Salsa is performing the same as asound using "hw", except one other perhaps trivial thing I have noticed. The aplay code does err = snd_output_stdio_attach(&log, stderr, 0); and prints things snd_pcm_hw_params_dump(params, log); finishing with snd_output_close(log) In alsa-lib, the third parameter of .._attach is used to set 'close', and being 0, means stderr is not closed. However, with salsa the file is always closed at the end. I am using the aplay code as a function, and on the 2nd call, there are non of the print items. Preventing this close in salsa or the aplay code does remove the problem. Is this intended trimming of functionality for min size?
Ah, that stupid wrapper for FILE I/O. I don't understand why such a thing was introduced...
Not sure whether I'll fix it or leave it yet.
Takashi
On Friday 20 July 2007 13:10, you wrote:
At Fri, 20 Jul 2007 12:57:07 +0100,
Alan Horstmann wrote:
OK. Salsa is performing the same as asound using "hw", except one other perhaps trivial thing I have noticed. The aplay code does err = snd_output_stdio_attach(&log, stderr, 0); and prints things snd_pcm_hw_params_dump(params, log); finishing with snd_output_close(log) In alsa-lib, the third parameter of .._attach is used to set 'close', and being 0, means stderr is not closed. However, with salsa the file is always closed at the end. I am using the aplay code as a function, and on the 2nd call, there are non of the print items. Preventing this close in salsa or the aplay code does remove the problem. Is this intended trimming of functionality for min size?
Ah, that stupid wrapper for FILE I/O. I don't understand why such a thing was introduced...
Not sure whether I'll fix it or leave it yet.
Actually, if my reading of the code is right (which it may not be), in alsa-lib all that snd_output_close(..) does is close(file) if 'close'=1.
So if the aplay code does .._attach with 'close'=0, is there any reason to call snd_output_close(..)? Or just omit that? So probably no fix needed?
Alan
At Fri, 20 Jul 2007 16:20:49 +0100, Alan Horstmann wrote:
On Friday 20 July 2007 13:10, you wrote:
At Fri, 20 Jul 2007 12:57:07 +0100,
Alan Horstmann wrote:
OK. Salsa is performing the same as asound using "hw", except one other perhaps trivial thing I have noticed. The aplay code does err = snd_output_stdio_attach(&log, stderr, 0); and prints things snd_pcm_hw_params_dump(params, log); finishing with snd_output_close(log) In alsa-lib, the third parameter of .._attach is used to set 'close', and being 0, means stderr is not closed. However, with salsa the file is always closed at the end. I am using the aplay code as a function, and on the 2nd call, there are non of the print items. Preventing this close in salsa or the aplay code does remove the problem. Is this intended trimming of functionality for min size?
Ah, that stupid wrapper for FILE I/O. I don't understand why such a thing was introduced...
Not sure whether I'll fix it or leave it yet.
Actually, if my reading of the code is right (which it may not be), in alsa-lib all that snd_output_close(..) does is close(file) if 'close'=1.
So if the aplay code does .._attach with 'close'=0, is there any reason to call snd_output_close(..)? Or just omit that? So probably no fix needed?
It frees the internal buffer and allocated records. But for aplay it's not inevitablly necessary.
Takashi
participants (7)
-
Alan Horstmann -
James Courtier-Dutton -
Jaroslav Kysela -
John Rigg -
Lee Revell -
stan -
Takashi Iwai