[alsa-devel] Maximum buffer size on HDA
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
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
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.
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
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.
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
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
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
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
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
participants (3)
-
Jaroslav Kysela -
Lennart Poettering -
Takashi Iwai