From owner-freebsd-multimedia@FreeBSD.ORG Fri Jan 18 14:21:45 2008 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020B516A417 for ; Fri, 18 Jan 2008 14:21:45 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2DA13C461 for ; Fri, 18 Jan 2008 14:21:44 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A5387.dip.t-dialin.net [84.154.83.135]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id m0IELb2s004204; Fri, 18 Jan 2008 14:21:41 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m0IENaM9034224; Fri, 18 Jan 2008 15:23:36 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m0IENFAL087176; Fri, 18 Jan 2008 15:23:36 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200801181423.m0IENFAL087176@fire.js.berklix.net> To: Ian Smith In-reply-to: References: Comments: In-reply-to Ian Smith message dated "Thu, 17 Jan 2008 15:30:35 +1100." Date: Fri, 18 Jan 2008 15:23:15 +0100 From: "Julian H. Stacey" Cc: freebsd-multimedia@freebsd.org Subject: Re: forcing more sound buffering X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 14:21:45 -0000 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: 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