Thanks so much for all the infos. Tomorrow I'll give it some time. At the moment, I wanted to try out a different device on the same machine: Terretec Aureon USB audio. The result is even worse: short pieces of audio one after the other. Retrying the same file on the main audio device, I noticed it's not exactly stuttering, but it's like during time it gets "snowed" with white noise, more and more. Tomorrow I'll take a look better. Gabriele. Da: Garrett D'Amore A: [email protected] Data: 6 gennaio 2014 20.20.28 CET Oggetto: Re: [discuss] Re: audio stuttering 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/?&id; secret=22003744-e9cd8436 Powered by Listbox: http://www.listbox.com illumos-discuss | Archives | Modify Your Subscription
------------------------------------------- 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
