period/buffer bug on pmac ?

period/buffer bug on pmac ?

[danny]

In the process of fixing up the alsa output plugin of bmp a bit I've come 
upon a weird problem. The mp3s I was playing played to fast, with a 
audible click each few millisecond. This seemed to only happen when the 
period size was not a power of 2 (the output plugin used to set 
period_time). I've now calculated the period_size myself from the rate and 
set it to the nearest power of 2. Which seems to work fine, except in the 
case that the mp3 i play is not your regular 441000 kbs encoded, but for 
instance 32000. 

No error occurs on setting the rate (and it gets set at 
32000, although I doubt that the card, a pmac snapper, can do this) It 
seems that period size and buffersize get downscaled with a factor 
441000/32000. And the weird screwed up sound occurs again with these mp3s. 
The strangest thing is that although snd_pcm_params_get_* returns, 
for instance, 32000, 5944 and 763 for rate, buffersize and periodsize 
respectively, a cat /proc/asound/card0/pcm0p/sub0/hw_params tells me that 
actually the rate is 44100 and buffer 8192 and period 1015 (I also checked 
on my x86 with sblive, but there the proc entry says that the rate is 
32000, so I assume that card can downsample in hardware?).

Is this a bug in the driver or normal behaviour? If it is the last, how 
should I set the periodsize to something that both corresponds with the 
users preferenced sample time and with the fact that it apparently, has to 
be a power of 2?

danny







-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: period/buffer bug on pmac ?

[danny]

On Thu, 11 Nov 2004 danny@mailmij.org wrote:

> 
> In the process of fixing up the alsa output plugin of bmp a bit I've come 
> upon a weird problem. The mp3s I was playing played to fast, with a 
> audible click each few millisecond. This seemed to only happen when the 
> period size was not a power of 2 (the output plugin used to set 
> period_time). I've now calculated the period_size myself from the rate and 
> set it to the nearest power of 2. Which seems to work fine, except in the 
> case that the mp3 i play is not your regular 441000 kbs encoded, but for 
> instance 32000. 
> 
> No error occurs on setting the rate (and it gets set at 
> 32000, although I doubt that the card, a pmac snapper, can do this) It 
> seems that period size and buffersize get downscaled with a factor 
> 441000/32000. And the weird screwed up sound occurs again with these mp3s. 
> The strangest thing is that although snd_pcm_params_get_* returns, 
> for instance, 32000, 5944 and 763 for rate, buffersize and periodsize 
> respectively, a cat /proc/asound/card0/pcm0p/sub0/hw_params tells me that 
> actually the rate is 44100 and buffer 8192 and period 1015 (I also checked 
> on my x86 with sblive, but there the proc entry says that the rate is 
> 32000, so I assume that card can downsample in hardware?).
> 
> Is this a bug in the driver or normal behaviour? If it is the last, how 
> should I set the periodsize to something that both corresponds with the 
> users preferenced sample time and with the fact that it apparently, has to 
> be a power of 2?
> 

Seems everybody is talking about period/buffer size but nobody can tell me 
whether the above is a bug in alsa or not?
I can't fix it if I cannot get a hint...

d.




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: period/buffer bug on pmac ?

[Clemens Ladisch]

danny@mailmij.org wrote:
> In the process of fixing up the alsa output plugin of bmp a bit I've come
> upon a weird problem. The mp3s I was playing played to fast, with a
> audible click each few millisecond. This seemed to only happen when the
> period size was not a power of 2 (the output plugin used to set
> period_time). I've now calculated the period_size myself from the rate and
> set it to the nearest power of 2. Which seems to work fine,

There is no general power-of-2 requirement in ALSA.  The pmac driver
doesn't set a hardware constraint; if the hardware requires power-of-2
periods, it's a bug in the driver.

> except in the case that the mp3 i play is not your regular 441000
> kbs encoded, but for instance 32000.
>
> No error occurs on setting the rate (and it gets set at
> 32000, although I doubt that the card, a pmac snapper, can do this) It
> seems that period size and buffersize get downscaled with a factor
> 441000/32000. And the weird screwed up sound occurs again with these mp3s.
> The strangest thing is that although snd_pcm_params_get_* returns,
> for instance, 32000, 5944 and 763 for rate, buffersize and periodsize
> respectively, a cat /proc/asound/card0/pcm0p/sub0/hw_params tells me that
> actually the rate is 44100 and buffer 8192 and period 1015

The "default" device uses the "plug" plugin for automatic sample rate
conversion.


HTH
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: period/buffer bug on pmac ?

[Giuliano Pochini]

On 15-Nov-2004 Clemens Ladisch wrote:
> danny@mailmij.org wrote:
>> In the process of fixing up the alsa output plugin of bmp a bit I've come
>> upon a weird problem. The mp3s I was playing played to fast, with a
>> audible click each few millisecond. This seemed to only happen when the
>> period size was not a power of 2 (the output plugin used to set
>> period_time). I've now calculated the period_size myself from the rate and
>> set it to the nearest power of 2. Which seems to work fine,
> 
> There is no general power-of-2 requirement in ALSA.  The pmac driver
> doesn't set a hardware constraint; if the hardware requires power-of-2
> periods, it's a bug in the driver.

There in so such constraint set in the driver indeed. I don't know
that hardware, but it seems (at least on my G4MDD which has a Snapper
chip) that po2 is required.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: period/buffer bug on pmac ?

[danny]

On Mon, 15 Nov 2004, Clemens Ladisch wrote:

> danny@mailmij.org wrote:
> > In the process of fixing up the alsa output plugin of bmp a bit I've come
> > upon a weird problem. The mp3s I was playing played to fast, with a
> > audible click each few millisecond. This seemed to only happen when the
> > period size was not a power of 2 (the output plugin used to set
> > period_time). I've now calculated the period_size myself from the rate and
> > set it to the nearest power of 2. Which seems to work fine,
> 
> There is no general power-of-2 requirement in ALSA.  The pmac driver
> doesn't set a hardware constraint; if the hardware requires power-of-2
> periods, it's a bug in the driver.
> 
Thanks for the reply!
I've been hacking around a bit in the driver and think it needs some 
contraints, although its not (like i first thought) limited to a power of 
2. Constraining periods to integer and requiring at least 3 periods seem 
to fix all issues i have. However, these requirements sometimes 
drastically affect the period AND buffersize requested by the app. I play 
with it a bit more and submit a patch soon. 

d.




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: period/buffer bug on pmac ?

[Takashi Iwai]

At Tue, 16 Nov 2004 19:37:39 +0100 (CET),
<danny@mailmij.org> wrote:
> 
> On Mon, 15 Nov 2004, Clemens Ladisch wrote:
> 
> > danny@mailmij.org wrote:
> > > In the process of fixing up the alsa output plugin of bmp a bit I've come
> > > upon a weird problem. The mp3s I was playing played to fast, with a
> > > audible click each few millisecond. This seemed to only happen when the
> > > period size was not a power of 2 (the output plugin used to set
> > > period_time). I've now calculated the period_size myself from the rate and
> > > set it to the nearest power of 2. Which seems to work fine,
> > 
> > There is no general power-of-2 requirement in ALSA.  The pmac driver
> > doesn't set a hardware constraint; if the hardware requires power-of-2
> > periods, it's a bug in the driver.
> > 
> Thanks for the reply!
> I've been hacking around a bit in the driver and think it needs some 
> contraints, although its not (like i first thought) limited to a power of 
> 2. Constraining periods to integer and requiring at least 3 periods seem 
> to fix all issues i have.

That's good to know!

>  However, these requirements sometimes 
> drastically affect the period AND buffersize requested by the app. I play 
> with it a bit more and submit a patch soon. 

Don't forget summary and signed-off-by lines :)


thanks,

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8