PCM format restrict dilema

PCM format restrict dilema

[Manuel Jander]

Hello,

I have the following dilema. The Aureal Vortex DMA engine supports
upto 4 hardware pages, but they have to be frame aligned. The current
driver also needs them to be of the same size. To archive this, i added
the following code in the pcm "open" function.

/* Force equal size periods */
if ((err = snd_pcm_hw_constraint_integer(runtime,
SNDRV_PCM_HW_PARAM_PERIODS)) < 0)
return err;
/* Force DMA 32 bit alignment */
if ((err = snd_pcm_hw_constraint_step(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4)) < 0)
return err;

Now PCM works correctly, but some apps, like aplay fail to play some
formats, because they get their period size requirementes rejected, and
they just give up instead of trying other period sizes. Since aplay uses
a time based criteria for the period sizes instead of "sane" values, the
period sizes are very odd.

The question is, should i blame aplay or try to implement some
workaround in the Aureal driver ??

Best Regards.

Manuel Jander



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Takashi Iwai]

At Tue, 16 Sep 2003 10:19:53 -0400,
Manuel Jander wrote:
> 
> Hello,
> 
> I have the following dilema. The Aureal Vortex DMA engine supports
> upto 4 hardware pages, but they have to be frame aligned. The current
> driver also needs them to be of the same size. To archive this, i added
> the following code in the pcm "open" function.
> 
> /* Force equal size periods */
> if ((err = snd_pcm_hw_constraint_integer(runtime,
> SNDRV_PCM_HW_PARAM_PERIODS)) < 0)
> return err;
> /* Force DMA 32 bit alignment */
> if ((err = snd_pcm_hw_constraint_step(runtime, 0,
> SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4)) < 0)
> return err;
> 
> Now PCM works correctly, but some apps, like aplay fail to play some
> formats, because they get their period size requirementes rejected, and
> they just give up instead of trying other period sizes. Since aplay uses
> a time based criteria for the period sizes instead of "sane" values, the
> period sizes are very odd.

yes, this is a known issue.
recently i've talked with Jaroslav about this theme, and we agreed
that it's a design flaw of the current configurator system.

> The question is, should i blame aplay or try to implement some
> workaround in the Aureal driver ??

i fixed aplay recently to allocate the period size first.
this works better than the former way (buffer -> period).
please try the cvs version.

about the influence of this bug: 
AFAIK, very rare applications use the time-based period/buffer size,
so this is not critical.  strangely enough, aplay is an exception :)

(btw, aplay has also options to specify the buffer/period sizes in
frames, but the time-based values are used as default.)


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Tue, 16 Sep 2003 10:19:53 -0400,
> Manuel Jander wrote:
> 
>>Hello,
>>
>>I have the following dilema. The Aureal Vortex DMA engine supports
>>upto 4 hardware pages, but they have to be frame aligned. The current
>>driver also needs them to be of the same size. To archive this, i added
>>the following code in the pcm "open" function.
>>
>>/* Force equal size periods */
>>if ((err = snd_pcm_hw_constraint_integer(runtime,
>>SNDRV_PCM_HW_PARAM_PERIODS)) < 0)
>>return err;
>>/* Force DMA 32 bit alignment */
>>if ((err = snd_pcm_hw_constraint_step(runtime, 0,
>>SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4)) < 0)
>>return err;
>>
>>Now PCM works correctly, but some apps, like aplay fail to play some
>>formats, because they get their period size requirementes rejected, and
>>they just give up instead of trying other period sizes. Since aplay uses
>>a time based criteria for the period sizes instead of "sane" values, the
>>period sizes are very odd.
> 
> 
> yes, this is a known issue.
> recently i've talked with Jaroslav about this theme, and we agreed
> that it's a design flaw of the current configurator system.
> 
> 
>>The question is, should i blame aplay or try to implement some
>>workaround in the Aureal driver ??
> 
> 
> i fixed aplay recently to allocate the period size first.
> this works better than the former way (buffer -> period).
> please try the cvs version.
> 
> about the influence of this bug: 
> AFAIK, very rare applications use the time-based period/buffer size,
> so this is not critical.  strangely enough, aplay is an exception :)
> 
> (btw, aplay has also options to specify the buffer/period sizes in
> frames, but the time-based values are used as default.)
> 
> 
> Takashi
> 

I help develop an application called xine.
We wish to use the function: -
dir=0;
err = snd_pcm_hw_params_set_buffer_time_near(this->audio_fd, params, 
&buffer_time, &dir);

We then try to set the period size to buffer_size / 8.

I have already found out that not all audio devices like an interger 
amount of periods, so this can fail in some circumstances.

I have two problems: -
1) Once one sets the buffer size, and then tries to set the period size 
near, and fails. One would think that one could then go back a try a 
different buffer size, but I have found this does not work.
2) The different combinations of setting period_size/time and 
buffer_size/time and the dependence between them seems to be very 
difficult to achieve for all sound cards.

I want to try and aim at 8 periods per buffer.
Common sense would tell me that one should be able to set the buffer 
size first, and then try to set the period size to buffer_size/8. But I 
should be able to use the set_period_size_near call so that it selects 
the next closest value, so that I achieve a result as close as possible 
to what I want. This seems to fail with the current setup on some sound 
cards, but works with other sound cards.

Can I assume that this is a bug in alsa, or some deeper issue.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Paul Davis]

>I want to try and aim at 8 periods per buffer.
>Common sense would tell me that one should be able to set the buffer 
>size first, and then try to set the period size to buffer_size/8. But I 

why don't you set the sizes based on frame counts, not time? i suspect
you're more likely to get better results.

>should be able to use the set_period_size_near call so that it selects 
>the next closest value, so that I achieve a result as close as possible 
>to what I want. This seems to fail with the current setup on some sound 
>cards, but works with other sound cards.

i hope you handle the failure to get buffer_size/8 properly ... you
need to be willing to go all the way to buffer_size/2 before
concluding that you can't configure the device.

--p



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[James Courtier-Dutton]

Paul Davis wrote:
>>I want to try and aim at 8 periods per buffer.
>>Common sense would tell me that one should be able to set the buffer 
>>size first, and then try to set the period size to buffer_size/8. But I 
> 
> 
> why don't you set the sizes based on frame counts, not time? i suspect
> you're more likely to get better results.

If the api for setting based on time it present, I would expect to be 
able to use it.

> 
> 
>>should be able to use the set_period_size_near call so that it selects 
>>the next closest value, so that I achieve a result as close as possible 
>>to what I want. This seems to fail with the current setup on some sound 
>>cards, but works with other sound cards.
> 
> 
> i hope you handle the failure to get buffer_size/8 properly ... you
> need to be willing to go all the way to buffer_size/2 before
> concluding that you can't configure the device.

I would expect to be able to use the "set_period_size_near" with 
direction +1, so if period_size=buffer_size/8 did not work, the alsa-lib 
would automatically select the next best one, even if it is 
buffer_size/2, but this seems to fail as well.

> 
> --p
> 
> 
> 

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Paul Davis]

>> why don't you set the sizes based on frame counts, not time? i suspect
>> you're more likely to get better results.
>
>If the api for setting based on time it present, I would expect to be 
>able to use it.

you can use it. but the thing is that you are probably requesting
times in msecs, whereas almost all PCI audio interfaces only have
periods and buffers sizes that are measured in frames.

this means you will likely never get the buffer size you asked
for. its kind of like asking for 3 pounds of cheese in a store that
only measures in kilograms. if you're happy with the approximation
that will result, go ahead. otherwise, figure it out in the "correct"
units.

otoh, for USB audio, its arguably better to use msecs. sigh :)

>> i hope you handle the failure to get buffer_size/8 properly ... you
>> need to be willing to go all the way to buffer_size/2 before
>> concluding that you can't configure the device.
>
>I would expect to be able to use the "set_period_size_near" with 
>direction +1, so if period_size=buffer_size/8 did not work, the alsa-lib 
>would automatically select the next best one, even if it is 
>buffer_size/2, but this seems to fail as well.

it may be that alsa-lib considers certain "distances" as too great to
be considered "near". however, i would agree with you that it should
work. on the other hand, if you ask for 8 periods/buffer *or more*,
this will definitely fail on many audio interfaces, since they can
only offer less. keep in mind the "direction" argument to
set_foobar_near.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Jaroslav Kysela]

On Tue, 16 Sep 2003, James Courtier-Dutton wrote:

> I help develop an application called xine.
> We wish to use the function: -
> dir=0;
> err = snd_pcm_hw_params_set_buffer_time_near(this->audio_fd, params,
> &buffer_time, &dir);
>
> We then try to set the period size to buffer_size / 8.
>
> I have already found out that not all audio devices like an interger
> amount of periods, so this can fail in some circumstances.
>
> I have two problems: -
> 1) Once one sets the buffer size, and then tries to set the period size
> near, and fails. One would think that one could then go back a try a
> different buffer size, but I have found this does not work.
> 2) The different combinations of setting period_size/time and
> buffer_size/time and the dependence between them seems to be very
> difficult to achieve for all sound cards.
>
> I want to try and aim at 8 periods per buffer.
> Common sense would tell me that one should be able to set the buffer
> size first, and then try to set the period size to buffer_size/8. But I
> should be able to use the set_period_size_near call so that it selects
> the next closest value, so that I achieve a result as close as possible
> to what I want. This seems to fail with the current setup on some sound
> cards, but works with other sound cards.
>
> Can I assume that this is a bug in alsa, or some deeper issue.

Well, I am trying to debug these problem from time to time and the result
is that 99% of all cases are not bugs, but the problem with the refine
algorithm. Note that all not-locked parameters are "refined" when a
parameter is restricted (set). It is step by step issue, so you cannot get
back and change a parameter which is already restricted (as you noted for
buffer_size). You need to begin with the "refine" sequence again (thus
begin with the snd_pcm_hw_params_any() or save the hw_params value - use
snd_pcm_hw_params_copy() - BEFORE the failing step and recover it when you
want to try another values).

I don't think that the algorithm is bad. It allows us to track all
hardware constraints. I would probably suggest for all developers to try
their values and if they fail, this step might be the last resort:

snd_pcm_hw_params_any()
snd_pcm_hw_params_set_access(your...access)
snd_pcm_hw_params_set_format(your...format)
snd_pcm_hw_params_set_channels(your...channels)
snd_pcm_hw_params_set_rate_near(your...rate)
snd_pcm_hw_params_set_periods_minmax(min = 2, max = 8)
# buffer size from 0.1sec to 1sec
snd_pcm_hw_params_set_buffer_time_minmax(min = 100000, 1000000)
snd_pcm_hw_params()

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Jaroslav Kysela]

On Tue, 16 Sep 2003, James Courtier-Dutton wrote:

> I would expect to be able to use the "set_period_size_near" with
> direction +1, so if period_size=buffer_size/8 did not work, the alsa-lib
> would automatically select the next best one, even if it is
> buffer_size/2, but this seems to fail as well.

We found that it fails in the case when buffer_size cannot be divided by
any value (buffer_size is odd). We cannot do anything to fix it at this
moment.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Tue, 16 Sep 2003, James Courtier-Dutton wrote:
> 
> 
>>I would expect to be able to use the "set_period_size_near" with
>>direction +1, so if period_size=buffer_size/8 did not work, the alsa-lib
>>would automatically select the next best one, even if it is
>>buffer_size/2, but this seems to fail as well.
> 
> 
> We found that it fails in the case when buffer_size cannot be divided by
> any value (buffer_size is odd). We cannot do anything to fix it at this
> moment.

Now that bit of infomation helps me a lot. I will therefore not use the 
buffer_time_near function any more, because it might decide on a 
buffer_size odd.

I can also not use buffer_size_near, because that might do the same.
So, I am reduced to using buffer_size together with application level 
retries to get a buffer size close to what I need. The trouble then, is 
that the application cannot access the contraints due to hardware, and 
thus, is really guessing in the dark.

I will also try the save state idea you gave in the last email, so I 
could try the buffer_time_near and period size functions, but it they 
fail use an alternative method. I could even have 3 methods, if method 1 
fails, try method 2, then try method 3. The different methods would 
consist of trying different functions/values based on an educated guess 
as to why the previous values did not work.

A possible solution to all this could be linking the period, periods, 
and buffer_size constraints.

So, the application does the following: -
1) I want there to be 8 periods or less, with a minimum of 2.
2) I want the buffer to be about 500ms long or less, with a minimum or 100ms
3) I want the period size to have a min value of x, and a max value or y.
4) Now calculate the actual sizes based on all the above information. 
(i.e. The buffer_size, and period_size values are not set until stage (4).
At this point, alsa-lib would use the contrains above, and calculate the 
best values for buffer_size and period size based on the above, and also 
what the hardware can do.

The reason I think it might help this way, is because period_size and 
buffer_size and number of periods are all closely linked, so we should 
not have to set them one at a time, but set them as a group.


> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs
> 
> 

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Jaroslav Kysela]

On Wed, 17 Sep 2003, Paul Davis wrote:

> >So, the application does the following: -
> >1) I want there to be 8 periods or less, with a minimum of 2.
> >2) I want the buffer to be about 500ms long or less, with a minimum or 100ms
> >3) I want the period size to have a min value of x, and a max value or y.
> >4) Now calculate the actual sizes based on all the above information.
> >(i.e. The buffer_size, and period_size values are not set until stage (4).
> >At this point, alsa-lib would use the contrains above, and calculate the
> >best values for buffer_size and period size based on the above, and also
> >what the hardware can do.
> >
> >The reason I think it might help this way, is because period_size and
> >buffer_size and number of periods are all closely linked, so we should
> >not have to set them one at a time, but set them as a group.
>
> given that buffer_size = period_size * nperiods, why try to set the
> buffer size at all? i've never set the buffer size in any ALSA app - i
> always set nperiods first, then the period size.

Good point. This algorithm sounds robust.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Jaroslav Kysela]

On Wed, 17 Sep 2003, James Courtier-Dutton wrote:

> The reason I think it might help this way, is because period_size and
> buffer_size and number of periods are all closely linked, so we should
> not have to set them one at a time, but set them as a group.

Yes, but it's violation of the current "refine" algorithm. When I talked
with Takashi, I would like to come with some preset values in alsa-lib
which describes the basic configurations for player applications etc.
These preset values will be hardware specific.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Paul Davis]

>So, the application does the following: -
>1) I want there to be 8 periods or less, with a minimum of 2.
>2) I want the buffer to be about 500ms long or less, with a minimum or 100ms
>3) I want the period size to have a min value of x, and a max value or y.
>4) Now calculate the actual sizes based on all the above information. 
>(i.e. The buffer_size, and period_size values are not set until stage (4).
>At this point, alsa-lib would use the contrains above, and calculate the 
>best values for buffer_size and period size based on the above, and also 
>what the hardware can do.
>
>The reason I think it might help this way, is because period_size and 
>buffer_size and number of periods are all closely linked, so we should 
>not have to set them one at a time, but set them as a group.

given that buffer_size = period_size * nperiods, why try to set the
buffer size at all? i've never set the buffer size in any ALSA app - i
always set nperiods first, then the period size.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Playback/Record speed mismatch

[Prince John]

Hi,
I have a Hitachi SH4 based embedded system with AD1881
codec. I have developed an ALSA driver for it and it
is functional. Now there is a problem that, the .wav
files when played back with 'aplay' are played back in
twice the speed. i.e, a .wav file of 48000 sample rate
and S16_LE format playsback in twice the speed than
expected. But if I set the the AD1881 DAC rate to
24000, the playback is fine. For recording also, I
have noticed the same speed difference (2:1) when I
play back the recorded file on a Windows PC. This
speed mismatch is seen for all sample rates. I hope I
have to set the playback/record rate as the DAC/ADC
rate. If so, why is this mismatch in speed?

Also, the I get 'unaligned access', or system hangs
when I use rate 44100 for rec/playback with 'aplay'
application.

I use alsa release 0.9.1
Please help me with your valuable suggestions.

Thanks,
Prince


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Wed, 17 Sep 2003, Paul Davis wrote:
> 
> 
>>>So, the application does the following: -
>>>1) I want there to be 8 periods or less, with a minimum of 2.
>>>2) I want the buffer to be about 500ms long or less, with a minimum or 100ms
>>>3) I want the period size to have a min value of x, and a max value or y.
>>>4) Now calculate the actual sizes based on all the above information.
>>>(i.e. The buffer_size, and period_size values are not set until stage (4).
>>>At this point, alsa-lib would use the contrains above, and calculate the
>>>best values for buffer_size and period size based on the above, and also
>>>what the hardware can do.
>>>
>>>The reason I think it might help this way, is because period_size and
>>>buffer_size and number of periods are all closely linked, so we should
>>>not have to set them one at a time, but set them as a group.
>>
>>given that buffer_size = period_size * nperiods, why try to set the
>>buffer size at all? i've never set the buffer size in any ALSA app - i
>>always set nperiods first, then the period size.
> 
> 
> Good point. This algorithm sounds robust.

How would that algorithm handle the "dmix" case, when nperiods != integer?

> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs
> 
> 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: PCM format restrict dilema

[Jaroslav Kysela]

On Wed, 17 Sep 2003, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> > On Wed, 17 Sep 2003, Paul Davis wrote:
> >
> >
> >>>So, the application does the following: -
> >>>1) I want there to be 8 periods or less, with a minimum of 2.
> >>>2) I want the buffer to be about 500ms long or less, with a minimum or 100ms
> >>>3) I want the period size to have a min value of x, and a max value or y.
> >>>4) Now calculate the actual sizes based on all the above information.
> >>>(i.e. The buffer_size, and period_size values are not set until stage (4).
> >>>At this point, alsa-lib would use the contrains above, and calculate the
> >>>best values for buffer_size and period size based on the above, and also
> >>>what the hardware can do.
> >>>
> >>>The reason I think it might help this way, is because period_size and
> >>>buffer_size and number of periods are all closely linked, so we should
> >>>not have to set them one at a time, but set them as a group.
> >>
> >>given that buffer_size = period_size * nperiods, why try to set the
> >>buffer size at all? i've never set the buffer size in any ALSA app - i
> >>always set nperiods first, then the period size.
> >
> >
> > Good point. This algorithm sounds robust.
>
> How would that algorithm handle the "dmix" case, when nperiods != integer?

Use near() set variants and get the real buffer size after you set the
hw_params.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf