forcing more sound buffering

[Ian Smith]

On Thu, 17 Jan 2008, Julian Stacey wrote:

 > I had sticky (intermittent breaks) sound on 2 slow hosts with 7-PRERELEASE
 > The causes of the stickiness are various &/or compound,
 > 	(eg slow CPU, DMA off (must be on mine), & PS2 mouse Giant

I think running ATA without DMA could likely be the cause of most of
your problems in this respect.  Have you tried getting that fixed?  My
'99 Compaq Armada 1500c (300MHz Celeron) has no problem with UDMA33, or
I doubt it'd be happy playing music files ok either ..

[..]
 >   /boot/loader.conf:
 >     hw.snd.feeder_buffersize=65536	# default 16384, read only after boot.
 > 	# Helped my intermittent music playing a lot (for .wav perfect,
 > 		mp3 improved from awful.
 > 		Maybe it should be ref'd in more manuals/ docs?

It doesn't appear at all in 5.5-STABLE (well, from some months ago now). 
Perhaps setting hw.snd.verbose=2 and showing `cat /dev/sndstat` during
playback might be informative? 

 > 		& docs should explain what it is:  Buffer size in bytes maybe ?

I expect so.

 > 		& how it relates to max delay expected from disc feeding
 > 		audio data.  ie (I'm guessing, it's late & I haven't
 > 		read source yet) if file reports eg
 >   audio_01.mp3: MPEG ADTS, layer III, v1, 128 kBits, 44.1 kHz, JntStereo
 > 		Does 64K give me just a half second of buffer ?
 > 		(not enough here !)

Assuming 128kbps that's 16Kbytes/sec, so 64K should give you ~4 seconds.
If you need anything like that much you do indeed have problems.

 > I guess ksmp3play uses less internal buffering than mplayer, ? With a .jpg:
 >  133MHz hw.snd.feeder_buffersize=16384 mplayer   : ran a bit rough.
 >  133MHz hw.snd.feeder_buffersize=65536 ksmp3play : awful
 >  133MHz hw.snd.feeder_buffersize=65536 mplayer   : still a bit broken.
 >  166MHz hw.snd.feeder_buffersize=16384 ksmp3play : awful
 >  166MHz hw.snd.feeder_buffersize=16384 mplayer:  : much better
 >  166MHz hw.snd.feeder_buffersize=65536 ksmp3play : broke up 
 >  166MHz hw.snd.feeder_buffersize=65536 mplayer   : pretty good, not perfect.
 > 
 > hw.snd.feeder_buffersize Max is 64K. 
 > 	I need more. Dont know if 64K is a horrible Intel
 > 	'86 IO seg limit, or just random choice. I'll try to tweak it.

I'm not sure it'd help.  How many vchans are you running?  What kern.hz?

 > What is the lowest speed CPU for playing `normal mp3 music (ie `file' above)
 > Am I being over ambitious or reasonable ?
 > What about decompression load on CPUs, buffering etc ?

Given that my ATA DMA works, my 5.5 vs your 7, my 300MHz laptop plays an
(average) ~160kbps VBR .mp3 using about 20% CPU with xmms, or about 15%
with mpg123 -v.  Doing little else, yours should just about make it, if
you can get ATA DMA working.  Without DMA, hmm, it seems less likely,
though of course somebody may spot some entirely different problem :) 

I've no idea how 'heavy' mplayer or ksmp3play are wrt xmms or mpg123.

 > BTW I earlier tried tweaking hw.snd.latency (without knowing what it was)
 > beyond max 10, but despite tweaking header (below) it went silent > 10.

I see little point fiddling with settings I don't understand :) but my
perhaps out of date wrt sound 5.5-S has different settings anyway.

Best I can offer is what happens here, playing this file:

paqi% ll ~/0/music/rf_livin.mp3
-r--r--r--  1 root  smithi  6322173 Jan 11  2003 /home/smithi/0/music/rf_livin.mp3

paqi% file ~/0/music/rf_livin.mp3
/home/smithi/0/music/rf_livin.mp3: MP3, 128 kBits, 44.1 kHz, JStereo

[ file, unsurprisingly, knows nothing about VBR .. see lame(1) :-]

paqi% sysctl kern.clockrate
kern.clockrate: { hz = 200, tick = 5000, profhz = 1024, stathz = 128 }

paqi% sysctl hw.snd
hw.snd.targetirqrate: 32
hw.snd.report_soft_formats: 1
hw.snd.verbose: 2
hw.snd.unit: 0
hw.snd.maxautovchans: 4
hw.snd.pcm0.buffersize: 4096
hw.snd.pcm0.vchans: 4

paqi% cat /dev/sndstat
FreeBSD Audio Driver (newpcm)
Installed devices:
pcm0: <ESS 1869 DSP> at io 0x220 irq 5 drq 1:5 bufsz 4096  (1p/1r/4v channels duplex default)
        [pcm0:record:0]: spd 22050, fmt 0x00000010, flags 0x00000000, 0x00000000
        interrupts 1, overruns 0, hfree 4096, sfree 131072
        {hardware} -> feeder_root(0x00000010) -> {userland}
        [pcm0:play:0]: spd 44100, fmt 0x10000010, flags 0x00001020, 0x00000000
        interrupts 92156, underruns 1082, ready 0
        {userland} -> feeder_vchan_s16(0x10000010) -> {hardware}
        pcm0:play:0[pcm0:virtual:0]: spd 44100, fmt 0x10000010, flags 0x10003030, 0x00000000, pid 1154
        interrupts 0, underruns 0, ready 131072
        {userland} -> feeder_root(0x10000010) -> {hardware}
        pcm0:play:0[pcm0:virtual:1]: spd 0, fmt 0x00000000/0x00000008, flags 0x10000000, 0x00000000
        interrupts 0, underruns 0, ready 0
        {userland} -> feeder_root(0x00000000) -> {hardware}
        pcm0:play:0[pcm0:virtual:2]: spd 0, fmt 0x00000000/0x00000008, flags 0x10000000, 0x00000000
        interrupts 0, underruns 0, ready 0
        {userland} -> feeder_root(0x00000000) -> {hardware}
        pcm0:play:0[pcm0:virtual:3]: spd 0, fmt 0x00000000/0x00000008, flags 0x10000000, 0x00000000
        interrupts 0, underruns 0, ready 0
        {userland} -> feeder_root(0x00000000) -> {hardware}

systat -vm showed: '86 5: sbc0' ie 86 sound interrupts/s (steady) during
the above playback, and rarely more than 0 average ata0 interrupts.

cheers, Ian