Actually, it looks like the playahead is already more than 10 msec (actually 15). Perhaps bumping it up a bit would help though. Try 20, 30, or even 40 to see if it gets you smoother playback.
The other thing that can be tuned is audio_intrhz. By default this is 100. Its tunable in /etc/system. You could try both raising and lowering it. My guess is lowering -- say to 48 or thereabouts, might help. I really need to add some more debugging here -- it would be nice to detect under runs, but sadly we don't always know. The hardware just treats the buffer as a circular fifo, and if we fall behind... well, bad things happen. Ultimately I really believe that the root cause of the stuttering is inconsistencies between the hardware clock used by the audio chip, and the system clock. Over a long period the drift can become problematic, which is probably why you don't see the problem until you've been running audio for a while. On Mon, Jan 6, 2014 at 11:08 AM, Garrett D'Amore <[email protected]> wrote: > Well.... I wrote or adapted most of that audio framework myself, so I'm > probably to blame for any problems. That said, I don't have access to most > of this audio hardware anymore and I've not thought much about it in years. > > Apparently OSS 4.2 fixes some of these issues -- the other thing is that > if the system clock is "unreliable", you might see some stuttering as back > in the late days of boomer I made a change to avoid using the device > specific interrupts and use the system clock for periodic polling. The > theory here was to avoid extra CPU overhead with another interrupt, and > also to provide "uniform" audio buffering sizes (frags) to facilitate some > ideas I had for the future (I wanted to be able to move audio streams from > one device to another. That requires the devices to interrupt at the same > frequency, which real hardware devices almost never do.) In fact, these > changes busted VMware audio, because VMware's buggy implementation depends > on device interrupts. I never spent the time to fix it. > > In retrospect, it might be easier to just go back to device interrupts. > The changes at issue were made as a outback back in March 2010 -- see > PSARC 2009/674 (you can check the git log there.) You'll notice that build > 134 occurred in Feb of the same year, so its most likely that these changes > are to blame. > > One *very* simple change to try would be to change the value returned by > the audio810_playahead() routine to be something a bit larger. The older > ICH parts provide a 40 ms playahead, but perhaps this is a bit longish. I > suspect a playahead of at least 10 msec, and possibly as large as 20 msec, > may substantially help your stuttering. > > (Ideally this value should be handled as a tunable property, but > apparently I didn't write the code to make use of driver properties. This > is probably because I have an intense dislike of driver properties as > tuning mechanisms... driver.conf(4) is byzantine for PCI devices. :-) > > > > > On Sun, Jan 5, 2014 at 10:39 PM, Richard PALO <[email protected]>wrote: > >> There have been problems with certain AC97 devices since before illumos >> was even forked... >> >> one of the later reports is here: https://www.illumos.org/issues/638 >> >> what would be great is to find a maintainer to what has become seemingly >> out of date and certainly buggy. >> >> >> >> >> ------------------------------------------- >> illumos-discuss >> Archives: https://www.listbox.com/member/archive/182180/=now >> RSS Feed: https://www.listbox.com/member/archive/rss/182180/ >> 22003744-9012f59c >> Modify Your Subscription: https://www.listbox.com/ >> member/?& >> Powered by Listbox: http://www.listbox.com >> > > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
