HDAudio period/buffer sizes

HDAudio period/buffer sizes

[pl bossart]

When I look at the HDAudio spec, I see that the BDL entries need to be
aligned on a 128-byte boundary, but the buffer length can be any value.
When I look at the HDAudio driver (azx_pcm_open in hda_codec.c), I see
that we enforce a 128-byte granularity on the period/buffer sizes, but
this was added in a patch that fixed alignment issues (5f1545bc)

Any technical reason why the driver is more demanding than the spec? Or
is this a confusion between alignment and buffer size? I can understand
that rounding to multiple of 128 bytes would be more efficient in terms
of data access, but it also prevents applications from getting an
interrupt when they want (eg it's impossible to use 20ms periods with a
44.1kHz sampling rate, you'll get 19.59 or 20.31ms).

Thanks,
-Pierre

Re: HDAudio period/buffer sizes

[Takashi Iwai]

At Mon, 25 Jul 2011 18:47:38 -0500,
pl bossart wrote:
> 
> When I look at the HDAudio spec, I see that the BDL entries need to be
> aligned on a 128-byte boundary, but the buffer length can be any value.
> When I look at the HDAudio driver (azx_pcm_open in hda_codec.c), I see
> that we enforce a 128-byte granularity on the period/buffer sizes, but
> this was added in a patch that fixed alignment issues (5f1545bc)
> 
> Any technical reason why the driver is more demanding than the spec? Or
> is this a confusion between alignment and buffer size? I can understand
> that rounding to multiple of 128 bytes would be more efficient in terms
> of data access, but it also prevents applications from getting an
> interrupt when they want (eg it's impossible to use 20ms periods with a
> 44.1kHz sampling rate, you'll get 19.59 or 20.31ms).

Note that the buffer itself was already aligned to 128 bytes from the
very beginning as it's allocated via dma_alloc_coherent().
The fact that the commit fixes the real problem means that the buffer
size must be aligned, too, at least for some hardware.


Takashi

Re: HDAudio period/buffer sizes

[Takashi Iwai]

At Tue, 26 Jul 2011 14:23:40 -0500,
Pierre-Louis Bossart wrote:
> 
> that the buffer itself was already aligned to 128 bytes from the
> > very beginning as it's allocated via dma_alloc_coherent().
> > The fact that the commit fixes the real problem means that the buffer
> > size must be aligned, too, at least for some hardware.
> 
> I checked internally and the reply was "There is no requirement the buffer 
> must be 128 byte multiples.  As long as it is integer number of samples, we
> are good."
> 
> What's the best way to deal with it? Add a driver option? A compilation
> option?

I'd say a driver option since this must be dynamically adjustable.
Care to make a patch?

For 3.2 (after 3.1 merge window), we can disable 128-bytes limit as
default again for testing.  If someone hits the problem, he can switch
easily and we can investigate more at this time.


thanks,

Takashi

Re: HDAudio period/buffer sizes

[Raymond Yau]

2011/7/27 Takashi Iwai <tiwai@suse.de>:
> At Tue, 26 Jul 2011 14:23:40 -0500,
> Pierre-Louis Bossart wrote:
>>
>> that the buffer itself was already aligned to 128 bytes from the
>> > very beginning as it's allocated via dma_alloc_coherent().
>> > The fact that the commit fixes the real problem means that the buffer
>> > size must be aligned, too, at least for some hardware.
>>
>> I checked internally and the reply was "There is no requirement the buffer
>> must be 128 byte multiples.  As long as it is integer number of samples, we
>> are good."
>>
>> What's the best way to deal with it? Add a driver option? A compilation
>> option?
>
> I'd say a driver option since this must be dynamically adjustable.
> Care to make a patch?
>
> For 3.2 (after 3.1 merge window), we can disable 128-bytes limit as
> default again for testing.  If someone hits the problem, he can switch
> easily and we can investigate more at this time.
>
>
The patch seem fix the problem of
snd_pcm_hw_params_set_period_time_near() to 120ms at 11025Hz for those
ad198x codec which are the only HDA codecs which support 11025Hz and
22050Hz

Does it mean that the period_bytes_min =128 can also be removed to
achieve lowest latency ?

Re: HDAudio period/buffer sizes

[Takashi Iwai]

At Sun, 14 Aug 2011 09:44:26 +0800,
Raymond Yau wrote:
> 
> 2011/7/27 Takashi Iwai <tiwai@suse.de>:
> > At Tue, 26 Jul 2011 14:23:40 -0500,
> > Pierre-Louis Bossart wrote:
> >>
> >> that the buffer itself was already aligned to 128 bytes from the
> >> > very beginning as it's allocated via dma_alloc_coherent().
> >> > The fact that the commit fixes the real problem means that the buffer
> >> > size must be aligned, too, at least for some hardware.
> >>
> >> I checked internally and the reply was "There is no requirement the buffer
> >> must be 128 byte multiples.  As long as it is integer number of samples, we
> >> are good."
> >>
> >> What's the best way to deal with it? Add a driver option? A compilation
> >> option?
> >
> > I'd say a driver option since this must be dynamically adjustable.
> > Care to make a patch?
> >
> > For 3.2 (after 3.1 merge window), we can disable 128-bytes limit as
> > default again for testing.  If someone hits the problem, he can switch
> > easily and we can investigate more at this time.
> >
> >
> The patch seem fix the problem of
> snd_pcm_hw_params_set_period_time_near() to 120ms at 11025Hz for those
> ad198x codec which are the only HDA codecs which support 11025Hz and
> 22050Hz
> 
> Does it mean that the period_bytes_min =128 can also be removed to
> achieve lowest latency ?

It depends on the sample rate (of course, 128byte itself defines the
limit, though).  The problem is for sample rates that can't be divided
by 8khz.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: HDAudio period/buffer sizes

[Pierre-Louis Bossart]

> > Does it mean that the period_bytes_min =128 can also be removed to
> > achieve lowest latency ?

Not sure who would want a latency lower than 0.66ms @ 48kHz? Looks to me like opening a can of worms.
-Pierre