forcing more sound buffering

[Julian H. Stacey]

Ian Smith wrote:
> 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
...............................Whoops I meant must be OFF on mine else no boot.

> 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?  

Not till now:
/boot/loader.conf has
	hw.ata.ata_dma=0                # Essential else disk access fails.
As both hosts lapd & lapn failed to boot without it

both hosts
	atacontrol cap ad0
		dma supported
	atacontrol mode ad0
		current mode = PIO4
host=lapn
	dmesg
		ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire
	sysctl -a | grep -i dma
		vfs.nfs.iodmax: 20
		vfs.nfs.iodmaxidle: 120
		hw.ata.atapi_dma: 1
		hw.ata.ata_dma: 0
		hw.busdma.total_bpages: 32
		hw.busdma.zone0.total_bpages: 32
		hw.busdma.zone0.free_bpages: 32
		hw.busdma.zone0.reserved_bpages: 0
		hw.busdma.zone0.active_bpages: 0
		hw.busdma.zone0.total_bounced: 0
		hw.busdma.zone0.total_deferred: 0
		hw.busdma.zone0.lowaddr: 0xffffffff
		hw.busdma.zone0.alignment: 2
		hw.busdma.zone0.boundary: 65536
		dev.atdma.0.%desc: AT DMA controller
		dev.atdma.0.%driver: atdma
		dev.atdma.0.%pnpinfo: pnpid=PNP0200
		dev.atdma.0.%parent: isa0
host=lapd
	dmesg	Something truncing it ... later

On my host=lapd
	atacontrol mode ad0
		current mode = PIO4 # runs OK
	atacontrol mode ad0 WDMA2
		current mode = WDMA2 
			Make disc activity survives. without crashing.
	ksmp3play *.mp3	# still plays with interrupts
	mpg123 -b 2048 *.mp3 # still plays with interrupts
	mplayer audio_01.mp3
		# breakages
	mplayer -cache 4096 -audiofile-cache 4096 -cache-min 80 *.mp3
		# breakage after a bit
	atacontrol mode ad0 UDMA2 # (alias UDMA33)
		current mode = UDMA33	# System Crashes
Not sure what the difference is between PIO4 & WDMA2.

> 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

Done. Latest dmesg in
 http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/dmesg/

> and showing `cat /dev/sndstat` during
> playback might be informative? 

Oh, didnt know that was possible either, (if you were in Munich, not Oz I'd
be buying you a beer, I seem to be learning, Thanks :-)   Done, to
 http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/sndstat/
I see:
 	underruns 2816		# I guess thats the breaks I'm hearing.
Under runs on my other non dma 7 laptop (host=lapd) too.

Reckon I need to get DMA working somehow, & check irqs & mem buf allocation
too probably.

>  > 		& 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.

Ah yes, thanks had forgotten thats 128K Bit not Bytes/sec. 

> If you need anything like that much you do indeed have problems.

Yes. X 2 !

>  > 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?  

Default, never tried anything with vchans
	hw.snd.maxautovchans: 16
	dev.pcm.0.play.vchans: 1
	dev.pcm.0.play.vchanrate: 46794
	dev.pcm.0.play.vchanformat: s16le
	dev.pcm.0.rec.vchans: 1
	dev.pcm.0.rec.vchanrate: 46794
	dev.pcm.0.rec.vchanformat: s16le


> What kern.hz?

kern.hz="100"
>From your previous suggestion on stable@ (where I still havent dinished
processing/ responded all in your last helpful posting (still in Drafts/ )

> 
>  > 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) :-]

Just read, re VBR thanks.


> 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

Mine are
	hw.snd.latency_profile: 1
	hw.snd.latency: 10
	hw.snd.report_soft_formats: 1
	hw.snd.compat_linux_mmap: 0
	hw.snd.feeder_buffersize: 131072
	hw.snd.feeder_rate_round: 25
	hw.snd.feeder_rate_max: 2016000
	hw.snd.feeder_rate_min: 1
	hw.snd.verbose: 2
	hw.snd.maxautovchans: 16
	hw.snd.default_unit: 0
	hw.snd.version: 2007061600/i386
	hw.snd.default_auto: 0


> 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.

91 here.
OK, I must read man systat too !

> cheers, Ian


Umm 1 more thing not helping as such is I have:
swapinfo:
	host=lapn
		Device          1K-blocks     Used    Avail Capacity
		/dev/ad0s1b        102400        0   102400     0%
		/dev/ad0s2b        102400        0   102400     0%
		Total              204800        0   204800     0%

	host=lapd
		Device          1K-blocks     Used    Avail Capacity
		/dev/ad0s1b        102400     6336    96064     6%
		/dev/md0           100000     6444    93556     6%
		Total              202400    12780   189620     6%
I'll try turning them off, at least the split to reduce head seek,
though theres no processes busy needing to swap, so dont expect much.

Any more ideas please say.
Thanks ! 

-- 
Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com