* Maximum buffer size on HDA @ 2008-06-13 19:13 Lennart Poettering 2008-06-16 10:32 ` Takashi Iwai 2008-06-16 10:32 ` Takashi Iwai 0 siblings, 2 replies; 10+ messages in thread From: Lennart Poettering @ 2008-06-13 19:13 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-13 19:13 Maximum buffer size on HDA Lennart Poettering @ 2008-06-16 10:32 ` Takashi Iwai 2008-06-16 10:53 ` Jaroslav Kysela 2008-06-16 10:32 ` Takashi Iwai 1 sibling, 1 reply; 10+ messages in thread From: Takashi Iwai @ 2008-06-16 10:32 UTC (permalink / raw) To: Lennart Poettering; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-16 10:32 ` Takashi Iwai @ 2008-06-16 10:53 ` Jaroslav Kysela 2008-06-16 12:11 ` Takashi Iwai 0 siblings, 1 reply; 10+ messages in thread From: Jaroslav Kysela @ 2008-06-16 10:53 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Lennart Poettering 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-16 10:53 ` Jaroslav Kysela @ 2008-06-16 12:11 ` Takashi Iwai 2008-06-16 12:29 ` Jaroslav Kysela 0 siblings, 1 reply; 10+ messages in thread From: Takashi Iwai @ 2008-06-16 12:11 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: alsa-devel, Lennart Poettering 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-16 12:11 ` Takashi Iwai @ 2008-06-16 12:29 ` Jaroslav Kysela 2008-06-16 12:37 ` Lennart Poettering 2008-06-16 12:42 ` Takashi Iwai 0 siblings, 2 replies; 10+ messages in thread From: Jaroslav Kysela @ 2008-06-16 12:29 UTC (permalink / raw) To: Takashi Iwai; +Cc: ALSA development, Lennart Poettering 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-16 12:29 ` Jaroslav Kysela @ 2008-06-16 12:37 ` Lennart Poettering 2008-06-19 17:42 ` Lennart Poettering 2008-06-16 12:42 ` Takashi Iwai 1 sibling, 1 reply; 10+ messages in thread From: Lennart Poettering @ 2008-06-16 12:37 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-16 12:37 ` Lennart Poettering @ 2008-06-19 17:42 ` Lennart Poettering 2008-06-20 7:10 ` Takashi Iwai 0 siblings, 1 reply; 10+ messages in thread From: Lennart Poettering @ 2008-06-19 17:42 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-19 17:42 ` Lennart Poettering @ 2008-06-20 7:10 ` Takashi Iwai 0 siblings, 0 replies; 10+ messages in thread From: Takashi Iwai @ 2008-06-20 7:10 UTC (permalink / raw) To: Lennart Poettering; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-16 12:29 ` Jaroslav Kysela 2008-06-16 12:37 ` Lennart Poettering @ 2008-06-16 12:42 ` Takashi Iwai 1 sibling, 0 replies; 10+ messages in thread From: Takashi Iwai @ 2008-06-16 12:42 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: ALSA development, Lennart Poettering 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maximum buffer size on HDA 2008-06-13 19:13 Maximum buffer size on HDA Lennart Poettering 2008-06-16 10:32 ` Takashi Iwai @ 2008-06-16 10:32 ` Takashi Iwai 1 sibling, 0 replies; 10+ messages in thread From: Takashi Iwai @ 2008-06-16 10:32 UTC (permalink / raw) To: Lennart Poettering; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-06-20 7:10 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-06-13 19:13 Maximum buffer size on HDA Lennart Poettering 2008-06-16 10:32 ` Takashi Iwai 2008-06-16 10:53 ` Jaroslav Kysela 2008-06-16 12:11 ` Takashi Iwai 2008-06-16 12:29 ` Jaroslav Kysela 2008-06-16 12:37 ` Lennart Poettering 2008-06-19 17:42 ` Lennart Poettering 2008-06-20 7:10 ` Takashi Iwai 2008-06-16 12:42 ` Takashi Iwai 2008-06-16 10:32 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.