On Fri, Aug 03, 2007 at 08:06:08PM +0200, Tim van der Molen wrote: > On Thu, 02 Aug 2007 22:04:13 +0200, Jacob Meuser wrote: > > On Thu, Jul 26, 2007 at 04:08:57AM +0200, Gareth wrote: > > > recently I updated my main desktop to -current (base and packages) from > > > -release (via snapshots) and I noticed problem with esound 0.2.38 (which I > > > need to use XMMS since my audio device is auich(4), only supporting 48khz > > > output) where it scratches and stutters a whole lot making most audio > > > unbearable. I was wondering if anyone else has had similar problems? > > > Also, esound 0.2.38 doesn't appear to read /etc/esd.conf any longer > > > (reading only ~/.esd.conf). I managed in a fully-unsupported and hackish > > > way to get back to 0.2.34 and it works fine so it isn't the hardware or > > > (as I initially thought) the changes to the kernel audio code recently. > > > I'm wondering if this is an esound problem (since they presumably don't > > > test too much on auich with bsd/sun audio over there) or an > > > openbsd-specific problem. Open to suggestions to fix this in a better > > > way. > > > > > > this is at least the second report of problems with esound. > > > > http://marc.info/?l=openbsd-ports&m=118405592003119&w=2 > > > > both these reports pretty much peg esound as the problem. > > > > unfortunately, we have audio devices that only support 48kHz sampling > > rate, and such audio daemons are a necessary evil to be able to play > > CDs and the release songs correctly. > > > > is this still a problem? anyone else having problems? > > I have the exact same problem as the one described above. Here is the > relevant part of my dmesg: > > auich0 at pci0 dev 31 function 5 "Intel 82801CA/CAM AC97" rev 0x01: irq 11, > ICH3 AC97 > ac97: codec id 0x83847609 (SigmaTel STAC9721/23) > ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D > > > I looked over esound, and the following patch is all I can see that > > could even remotely be a problem with the audio interface. > > I tested your patch using ogg123 and libao's esd module. > > The stuttering is almost completely gone, but ogg123 has problems to > start playing music.
interesting. seems auich is really picky about blocksize. what version of libao? it was updated to 0.8.8 on 7/12. > If I run ogg123, its time counter counts very fast for a while. > Meanwhile, I hear no sound. At some point, the time count is normal and > I hear the music stuttering for a moment, but after that it is fine. The > music stutters very seldomly. > > The duration of the `fast time count' depends on the time I haven't used > esound. The longer the time between two ogg123 invocations, the longer > the fast time count goes on. Waiting 10 seconds results in the fast time > count going to ~ 6 seconds; waiting ~ 5 minutes results in the fast time > count going to ~ 2.5 minutes. that sounds like pretty broken behaviour to me. I was already thinking there is a timing problem based on the previous reports, but this seems like definitive proof. > If you need more information, please let me know. if you could test with another audio device, that would be sweet. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
