Re: SALSA and aplay

Re: SALSA and aplay

[Takashi Iwai]

At Mon, 16 Jul 2007 13:40:23 +0100,
Alan Horstmann wrote:
> 
> Quick questions:
> 
> 1. 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)

> 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.

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

SALSA and aplay

[Alan Horstmann]

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

Re: SALSA and aplay

[Alan Horstmann]

On Monday 16 July 2007 13:30, you wrote:
> At Mon, 16 Jul 2007 13:40:23 +0100,
>
> Alan Horstmann wrote:
> > Quick questions:
> >
> > 1. 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

Re: SALSA and aplay

[Takashi Iwai]

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:
> > >
> > > 1. 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

Re: SALSA and aplay

[Alan Horstmann]

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

Re: SALSA and aplay

[Takashi Iwai]

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"), 
 };

Re: SALSA and aplay

[Alan Horstmann]

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

Re: SALSA and aplay

[Alan Horstmann]

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

Re: SALSA and aplay

[Takashi Iwai]

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

Re: SALSA and aplay

[Takashi Iwai]

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

Re: SALSA and aplay

[John Rigg]

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

Re: SALSA and aplay

[Takashi Iwai]

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

Re: SALSA and aplay

[John Rigg]

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

Re: SALSA and aplay

[Alan Horstmann]

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

Re: SALSA and aplay

[Takashi Iwai]

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

Hidden rate conversion, and Alsa configuration

[Alan Horstmann]

< 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

Re: SALSA and aplay

[Takashi Iwai]

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

Re: SALSA and aplay

[Alan Horstmann]

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

Re: Hidden rate conversion, and Alsa configuration

[stan]

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:
> 
> 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

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

Re: Hidden rate conversion, and Alsa configuration

[Jaroslav Kysela]

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:
> > 
> > 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
> 
> 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

Re: Hidden rate conversion, and Alsa configuration

[stan]

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:
> > > 
> > > 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
> > 
> > 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

Re: Hidden rate conversion, and Alsa configuration

[Lee Revell]

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

Re: Hidden rate conversion, and Alsa configuration

[Takashi Iwai]

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:
> >
> > 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.

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.

> > 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.

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

Re: Hidden rate conversion, and Alsa configuration

[Alan Horstmann]

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:
>
> 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?

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

Re: Hidden rate conversion, and Alsa configuration

[stan]

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?

Re: Hidden rate conversion, and Alsa configuration

[stan]

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.

Re: Hidden rate conversion, and Alsa configuration

[stan]

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#d0275f35954d3681fd8d016d5cf26749
that there are special functions
for this : snd_pcm_hw_open or _snd_pcm_hw_open.

Re: Hidden rate conversion, and Alsa configuration

[Lee Revell]

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

Re: Hidden rate conversion, and Alsa configuration

[stan]

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.

Re: Hidden rate conversion, and Alsa configuration

[Jaroslav Kysela]

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

Re: Hidden rate conversion, and Alsa configuration

[stan]

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.

Re: Hidden rate conversion, and Alsa configuration

[Alan Horstmann]

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

Re: Hidden rate conversion, and Alsa configuration

[James Courtier-Dutton]

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

Re: Hidden rate conversion, and Alsa configuration

[Takashi Iwai]

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

Re: Hidden rate conversion, and Alsa configuration

[Alan Horstmann]

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