Maximum buffer size on HDA

Maximum buffer size on HDA

[Lennart Poettering]

Heya,

the HDA driver allows a playback buffer size of something like 64K
onyl. Is this a driver limitation or a limitation of the hardware?
Skimming through the docs I cannot see anything like this, and I got
the idea that the audio buffer is maintained in system memory, not
sound card memory, so why this limit?

I'd like to buffer more than 64K, especially for surround playback in
PA. Something like 2s or so. I am kind of disappointed I can't do this
right now on HDA.

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Maximum buffer size on HDA

[Takashi Iwai]

At Fri, 13 Jun 2008 21:13:03 +0200,
Lennart Poettering wrote:
> 
> Heya,
> 
> the HDA driver allows a playback buffer size of something like 64K
> onyl. Is this a driver limitation or a limitation of the hardware?
> Skimming through the docs I cannot see anything like this, and I got
> the idea that the audio buffer is maintained in system memory, not
> sound card memory, so why this limit?

This comes from the buffer pre-allocator.
Run the below:

	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc

then you can use now 1MB buffer.  snd-hda-intel has max
pre-allocation buffer size 1MB, and this is the hard-coded limit.

It's rather a silly constraint, and I think it'd be better cut off.
OTOH, this makes the system safer (e.g. avoiding page allocations for
too large buffers), and there is a proper workaround, too.
So, I'm open about this change, so far.


Takashi

Re: Maximum buffer size on HDA

[Takashi Iwai]

At Fri, 13 Jun 2008 21:13:03 +0200,
Lennart Poettering wrote:
> 
> Heya,
> 
> the HDA driver allows a playback buffer size of something like 64K
> onyl. Is this a driver limitation or a limitation of the hardware?
> Skimming through the docs I cannot see anything like this, and I got
> the idea that the audio buffer is maintained in system memory, not
> sound card memory, so why this limit?

This comes from the buffer pre-allocator.
Run the below:

	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc

then you can use now 1MB buffer.  snd-hda-intel has max
pre-allocation buffer size 1MB, and this is the hard-coded limit.

It's rather a silly constraint, and I think it'd be better cut off.
OTOH, this makes the system safer (e.g. avoiding page allocations for
too large buffers), and there is a proper workaround, too.
So, I'm open about this change, so far.


Takashi

Re: Maximum buffer size on HDA

[Jaroslav Kysela]

On Mon, 16 Jun 2008, Takashi Iwai wrote:

> At Fri, 13 Jun 2008 21:13:03 +0200,
> Lennart Poettering wrote:
> > 
> > Heya,
> > 
> > the HDA driver allows a playback buffer size of something like 64K
> > onyl. Is this a driver limitation or a limitation of the hardware?
> > Skimming through the docs I cannot see anything like this, and I got
> > the idea that the audio buffer is maintained in system memory, not
> > sound card memory, so why this limit?
> 
> This comes from the buffer pre-allocator.
> Run the below:
> 
> 	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc
> 
> then you can use now 1MB buffer.  snd-hda-intel has max
> pre-allocation buffer size 1MB, and this is the hard-coded limit.
> 
> It's rather a silly constraint, and I think it'd be better cut off.
> OTOH, this makes the system safer (e.g. avoiding page allocations for
> too large buffers), and there is a proper workaround, too.
> So, I'm open about this change, so far.

Which workaround you're talking about?

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Maximum buffer size on HDA

[Takashi Iwai]

At Mon, 16 Jun 2008 12:53:11 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Mon, 16 Jun 2008, Takashi Iwai wrote:
> 
> > At Fri, 13 Jun 2008 21:13:03 +0200,
> > Lennart Poettering wrote:
> > > 
> > > Heya,
> > > 
> > > the HDA driver allows a playback buffer size of something like 64K
> > > onyl. Is this a driver limitation or a limitation of the hardware?
> > > Skimming through the docs I cannot see anything like this, and I got
> > > the idea that the audio buffer is maintained in system memory, not
> > > sound card memory, so why this limit?
> > 
> > This comes from the buffer pre-allocator.
> > Run the below:
> > 
> > 	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc
> > 
> > then you can use now 1MB buffer.  snd-hda-intel has max
> > pre-allocation buffer size 1MB, and this is the hard-coded limit.
> > 
> > It's rather a silly constraint, and I think it'd be better cut off.
> > OTOH, this makes the system safer (e.g. avoiding page allocations for
> > too large buffers), and there is a proper workaround, too.
> > So, I'm open about this change, so far.
> 
> Which workaround you're talking about?

Reset a proc file manually like the above.  Without this, you cannot
allocate the buffer over the pre-allocated size.


Takashi

Re: Maximum buffer size on HDA

[Jaroslav Kysela]

On Mon, 16 Jun 2008, Takashi Iwai wrote:

> At Mon, 16 Jun 2008 12:53:11 +0200 (CEST),
> Jaroslav Kysela wrote:
> > 
> > On Mon, 16 Jun 2008, Takashi Iwai wrote:
> > 
> > > At Fri, 13 Jun 2008 21:13:03 +0200,
> > > Lennart Poettering wrote:
> > > > 
> > > > Heya,
> > > > 
> > > > the HDA driver allows a playback buffer size of something like 64K
> > > > onyl. Is this a driver limitation or a limitation of the hardware?
> > > > Skimming through the docs I cannot see anything like this, and I got
> > > > the idea that the audio buffer is maintained in system memory, not
> > > > sound card memory, so why this limit?
> > > 
> > > This comes from the buffer pre-allocator.
> > > Run the below:
> > > 
> > > 	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc
> > > 
> > > then you can use now 1MB buffer.  snd-hda-intel has max
> > > pre-allocation buffer size 1MB, and this is the hard-coded limit.
> > > 
> > > It's rather a silly constraint, and I think it'd be better cut off.
> > > OTOH, this makes the system safer (e.g. avoiding page allocations for
> > > too large buffers), and there is a proper workaround, too.
> > > So, I'm open about this change, so far.
> > 
> > Which workaround you're talking about?
> 
> Reset a proc file manually like the above.  Without this, you cannot
> allocate the buffer over the pre-allocated size.

I'm not quite sure what you like to change. Make 1MB limit smaller? Or 
change the default preallocated size? Or remove preallocation? I think 
that it might make sense to increase the default preallocation value to 
128KB or 192KB.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Maximum buffer size on HDA

[Lennart Poettering]

On Mon, 16.06.08 14:29, Jaroslav Kysela (perex@perex.cz) wrote:

> > > > It's rather a silly constraint, and I think it'd be better cut off.
> > > > OTOH, this makes the system safer (e.g. avoiding page allocations for
> > > > too large buffers), and there is a proper workaround, too.
> > > > So, I'm open about this change, so far.
> > > 
> > > Which workaround you're talking about?
> > 
> > Reset a proc file manually like the above.  Without this, you cannot
> > allocate the buffer over the pre-allocated size.
> 
> I'm not quite sure what you like to change. Make 1MB limit smaller? Or 
> change the default preallocated size? Or remove preallocation? I think 
> that it might make sense to increase the default preallocation value to 
> 128KB or 192KB.

For PulseAudio it would be of big benefit if we could change the
default in a way the for the highest sensible sampling rate/number of
channels/sample type we'd always be able to get a two-second
buffer. Windows and Mac use 2s of buffer by default, and I think it
would make sense for PulseAudio to do that too. 

i.e. if the soundcard can do 2ch/16bit/44100hz at best I'd like to
have a buffer size of up to 344KB; if the soundcard can to
5.1/32bit/48000 at best then i'd like to have a buffer of up to 2.2MB
or so.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Maximum buffer size on HDA

[Takashi Iwai]

At Mon, 16 Jun 2008 14:29:03 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Mon, 16 Jun 2008, Takashi Iwai wrote:
> 
> > At Mon, 16 Jun 2008 12:53:11 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > > 
> > > On Mon, 16 Jun 2008, Takashi Iwai wrote:
> > > 
> > > > At Fri, 13 Jun 2008 21:13:03 +0200,
> > > > Lennart Poettering wrote:
> > > > > 
> > > > > Heya,
> > > > > 
> > > > > the HDA driver allows a playback buffer size of something like 64K
> > > > > onyl. Is this a driver limitation or a limitation of the hardware?
> > > > > Skimming through the docs I cannot see anything like this, and I got
> > > > > the idea that the audio buffer is maintained in system memory, not
> > > > > sound card memory, so why this limit?
> > > > 
> > > > This comes from the buffer pre-allocator.
> > > > Run the below:
> > > > 
> > > > 	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc
> > > > 
> > > > then you can use now 1MB buffer.  snd-hda-intel has max
> > > > pre-allocation buffer size 1MB, and this is the hard-coded limit.
> > > > 
> > > > It's rather a silly constraint, and I think it'd be better cut off.
> > > > OTOH, this makes the system safer (e.g. avoiding page allocations for
> > > > too large buffers), and there is a proper workaround, too.
> > > > So, I'm open about this change, so far.
> > > 
> > > Which workaround you're talking about?
> > 
> > Reset a proc file manually like the above.  Without this, you cannot
> > allocate the buffer over the pre-allocated size.
> 
> I'm not quite sure what you like to change. Make 1MB limit smaller? Or 
> change the default preallocated size? Or remove preallocation? I think 
> that it might make sense to increase the default preallocation value to 
> 128KB or 192KB.

We have some options:

A. Remove the sucking hw_constraint for the pre-allocated size
B. Remove/improve the whole pre-allocation mechanism
C. Increase the default pre-allocation size of snd-hda-intel
D. Ignore complains

I'm for, but still open about A.  B would be a good option if we can
(have time and resource).  C would be ad hoc but surely work for this
particular case.  D is the current status.


Takashi

Re: Maximum buffer size on HDA

[Lennart Poettering]

On Mon, 16.06.08 14:37, Lennart Poettering (mznyfn@0pointer.de) wrote:

heya!

> > I'm not quite sure what you like to change. Make 1MB limit smaller? Or 
> > change the default preallocated size? Or remove preallocation? I think 
> > that it might make sense to increase the default preallocation value to 
> > 128KB or 192KB.
> 
> For PulseAudio it would be of big benefit if we could change the
> default in a way the for the highest sensible sampling rate/number of
> channels/sample type we'd always be able to get a two-second
> buffer. Windows and Mac use 2s of buffer by default, and I think it
> would make sense for PulseAudio to do that too. 
> 
> i.e. if the soundcard can do 2ch/16bit/44100hz at best I'd like to
> have a buffer size of up to 344KB; if the soundcard can to
> 5.1/32bit/48000 at best then i'd like to have a buffer of up to 2.2MB
> or so.

Takashi, Jarsolav, how can I bribe you into increasing this limit?

What are the implications of this change? (Just wondering if it would
make sense for us to change this limit in the Fedora kernel packages)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Maximum buffer size on HDA

[Takashi Iwai]

At Thu, 19 Jun 2008 19:42:38 +0200,
Lennart Poettering wrote:
> 
> On Mon, 16.06.08 14:37, Lennart Poettering (mznyfn@0pointer.de) wrote:
> 
> heya!
> 
> > > I'm not quite sure what you like to change. Make 1MB limit smaller? Or 
> > > change the default preallocated size? Or remove preallocation? I think 
> > > that it might make sense to increase the default preallocation value to 
> > > 128KB or 192KB.
> > 
> > For PulseAudio it would be of big benefit if we could change the
> > default in a way the for the highest sensible sampling rate/number of
> > channels/sample type we'd always be able to get a two-second
> > buffer. Windows and Mac use 2s of buffer by default, and I think it
> > would make sense for PulseAudio to do that too. 
> > 
> > i.e. if the soundcard can do 2ch/16bit/44100hz at best I'd like to
> > have a buffer size of up to 344KB; if the soundcard can to
> > 5.1/32bit/48000 at best then i'd like to have a buffer of up to 2.2MB
> > or so.
> 
> Takashi, Jarsolav, how can I bribe you into increasing this limit?
> 
> What are the implications of this change? (Just wondering if it would
> make sense for us to change this limit in the Fedora kernel packages)

The max 1MB is the limitation of this driver implementation as
mentioned in previous posts.  It's not trivial to fix because of
SG-buffer handling.  HD-audio can have at most 256 BDL entries, and
a kernel page on x86* is 4kB, thus total 1MB.


Takashi