Re: Noisy audio - ALSA Configuration

Re: Noisy audio - ALSA Configuration

[Eliot Blennerhassett]

> Eliot,
> Thank you very much. Here is the message. If Hotmail is the problem I can
> subscribe using my work e-mail; I wanted to avoid that in the first place.
> Magdalena

The Hotmail message is all HTML, with no plaintext version.  I'm not sure if 
this list accpets html mails. OR  The text of the mail is all encapsulated in 
a number of HTML <DIV> blocks, maybe confused html to text converter...

Here is the original question:

> Does anyone have examples or documentation on how to configure periods,
> frames and buffers for various sample rates? I am writing a program to
> route a mp3 decoder output to ALSA on an ARM processor, and I get noisy
> audio. For a CD quality stream (S16_LE, 44100 kHz, Stereo, 128 bps) I am
> using an output buffer of 44100 bytes, a period of 44100/(channels*2). With

Be careful about the distinction between bytes and frames (i.e. a frame of 
stereo S16 is 4 bytes)

Start with the period 
1024 frames =  4096 bytes
then make your buffer at least 2x this:
8192 bytes

(I'm not an app developer, so others may jump in with a better explanation)

Did you look at the code in alsa-lib/test?

> a buffer this big, I do not get underruns, but I do get all short writes. I
> have not been able to find the right configuration to avoid short writes,
> and more importantly, to get good quality audio. What do 'short writes' (I
> am using writei) really mean? Is this a performance issue in the driver, or
> is mainly because of buffer setup? I would really appreciate any help with
> this.
> Magdalena

Re: Noisy audio - ALSA Configuration

[Iovescu, Magdalena]

>> Does anyone have examples or documentation on how to configure
periods,
>> frames and buffers for various sample rates? I am writing a
program to
>> route a mp3 decoder output to ALSA on an ARM processor, and I
get noisy
>> audio. For a CD quality stream (S16_LE, 44100 kHz, Stereo, 128
bps) I am
>> using an output buffer of 44100 bytes, a period of
44100/(channels*2). With
 
>>Be careful about the distinction between bytes and frames (i.e.
>>a frame of stereo S16 is 4 bytes)
 
>Start with the period 
>1024 frames =  4096 bytes
>then make your buffer at least 2x this:
>8192 bytes
 
> (I'm not an app developer, so others may jump in with a better
>explanation)
 
>Did you look at the code in alsa-lib/test?
 
Thanks Eliot, I will try this buffer size. 
 
I did look at alsa tests, but I was not too convinced, as when I run
those apps I still got plenty of short writes. Would someone please
explain why do these 'short writes' occur?
 
>> a buffer this big, I do not get underruns, but I do get all
short writes. I
>> have not been able to find the right configuration to avoid
short writes,
>> and more importantly, to get good quality audio. What do
'short writes' (I
>> am using writei) really mean? Is this a performance issue in
the driver, or
> is mainly because of buffer setup? I would really appreciate
any help with
>> this.
>> Magdalena

Noisy audio - ALSA Configuration

[Iovescu, Magdalena]

Does anyone have examples or documentation on how to configure periods,
frames and buffers for various sample rates?

I am writing a program to route a mp3 decoder output to ALSA on an ARM
processor, and I get noisy audio. For a CD quality stream (S16_LE, 44100
kHz, Stereo, 128 bps) I am using an output buffer of 44100 bytes, a
period of 44100/(channels*2). With a buffer this big, I do not get
underruns, but all the writes are short writes. I have not been able to
find the right configuration to avoid short writes, and more
importantly, to get good quality audio.

What do 'short writes' (I am using writei) really mean? Is this a
performance issue in the driver, or is mainly because of buffer setup?

I would really appreciate any help with this.

Mag

Re: Noisy audio - ALSA Configuration

[Clemens Ladisch]

Iovescu, Magdalena wrote:
> Does anyone have examples or documentation on how to configure periods,
> frames and buffers for various sample rates?

Frames don't need configuration; they are dependent on the sample format
only.  In your case (S16_LE, 2 channels), one frame = four bytes.

The buffer size determines latency.  Low latency is only important when
the audio data is generated from user input in real time; when you can
read (and decode) ahead, you should better use a rather large buffer to
reduce the possibility of underruns.

Periods aren't that important.  A period is the interval between two
interrupts, so it might be better to have more small periods than fewer
large ones (unless the interrupt overhead gets too high) so that your
application can get woken up more often, but there isn't much difference
in practice.

> [...] With a buffer this big, I do not get underruns, but all the
> writes are short writes. I have not been able to find the right
> configuration to avoid short writes,

Short writes happen where there is less free space in the buffer than
you are trying to write.  This is the normal case, there's nothing wrong
with that.  Is there a reason why you want to avoid them?


Regards,
Clemens

Re: Noisy audio - ALSA Configuration

[Iovescu, Magdalena]

Clemens,

Thanks. I wanted to avoid short writes as I thought that they may be the
cause of the noise I have in my audio.

What may be other reasons I get bad quality audio?

Magdalena

-----Original Message-----
From: Clemens Ladisch [mailto:cladisch@fastmail.net] 
Sent: Thursday, August 16, 2007 2:06 AM
To: Iovescu, Magdalena; alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Noisy audio - ALSA Configuration

Iovescu, Magdalena wrote:
> Does anyone have examples or documentation on how to configure
periods,
> frames and buffers for various sample rates?

Frames don't need configuration; they are dependent on the sample format
only.  In your case (S16_LE, 2 channels), one frame = four bytes.

The buffer size determines latency.  Low latency is only important when
the audio data is generated from user input in real time; when you can
read (and decode) ahead, you should better use a rather large buffer to
reduce the possibility of underruns.

Periods aren't that important.  A period is the interval between two
interrupts, so it might be better to have more small periods than fewer
large ones (unless the interrupt overhead gets too high) so that your
application can get woken up more often, but there isn't much difference
in practice.

> [...] With a buffer this big, I do not get underruns, but all the
> writes are short writes. I have not been able to find the right
> configuration to avoid short writes,

Short writes happen where there is less free space in the buffer than
you are trying to write.  This is the normal case, there's nothing wrong
with that.  Is there a reason why you want to avoid them?


Regards,
Clemens