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
