[PATCH] Re: [Fwd: Re: [mythtv] Your soundcard is not reporting free space correctly.]

[Bruce Markey]

Ann Patterson wrote:
> On Sat, 2004-03-27 at 12:02, Isaac Richards wrote:
> 
>>On Saturday 27 March 2004 12:22 pm, Ann Patterson wrote:
>>
>>>On Tue, 2004-03-09 at 19:32, Ann Patterson wrote:
>>>
>>>>On Mon, 2004-03-08 at 08:15, Ann Patterson wrote:
>>>>
>>>>>After even more debugging, and a reading of the OSS docs, I discovered
>>>>>that the values returned from ioctl(audio_fd, SNDCTL_DSP_GETOSPACE,
>>>>>&info) are undefined if you're not writing full fragments to the card.
>>>>>For every other card I tested, the values returned from this call were
>>>>>fine, even when writing partial fragments. But when I ran this with the
>>>>>M-Audio card, the values are all over the place. I was able to
>>>>>duplicate the problem with the alsa osstest program, writing blocks of
>>>>>1000 bytes. When I changed the osstest program to write 4096 bytes
>>>>>(this card's fragsize), the problem went away.
>>>>>
>>>>>Ann P.
>>>>
>>>>Here's a patch that sets the fragment size on the card to a reasonable
>>>>value, then writes the audio in full fragments. It fixes the problems
>>>>I'm having with the M-Audio card. I don't think it should hurt anything
>>>>else.
>>>>
>>>>Ann P.
>>>
>>>I submitted this patch a couple of weeks ago, and it got ignored.
>>>Recently, I've been getting emails from other people who have the same
>>>card, asking when the patch is going to be applied to CVS. This (or
>>>something similar) is required for this particular M-Audio card to work
>>>correctly with mythtv.
>>
>>I didn't apply it because it hadn't sounded like you tested it very much, and 
>>there were no reports of anyone else using it, either.  As it changes 
>>behavior for _everyone_, I think it needs at least a little testing before 
>>going into CVS.
>>
>>Isaac
> 
> 
> If you had told me that instead of just ignoring me, I would have
> attempted to get some volunteers to test, instead of waiting 3 weeks in
> limbo. It's only about 10 lines of pretty straightforward code, so I
> didn't think there would be a problem.
> 
> So, that said, I have tested the patch on the revo, and I can test it on
> the M-Audio Audiophile (ice1712), and maybe nforce. Are there volunteers
> to test on some other cards? Owners of M-Audio revolutions will thank
> you.

First, a couple suggestions (not criticism =).

- You may have wanted to attach your patch on this message. I
know you've sent it in other messages but it may have made
sense to include it here too.

-  You might want to include a few VERBOSE statements to verify
the fragment size or other info to help understand if the right
things are happening. Tester could then run "mythfrontend -v playback"
to see if they are getting sane values and such.

        VERBOSE(VB_PLAYBACK, QString("Audio fragment_size: %1")
                             .arg(fragment_size));

- Your comment that "I don't think it should hurt anything
else" was honest but probably wasn't reassuring to the person
who would receive hundreds of complaints if it did the wrong thing
on other sound cards. I (and others) am probably remiss for not
picking up on the fact that this isn't just a patch for M-Audio
only but applies to all cards and needs sanity testing.

- While it may have been good to get a response sooner, you may
want to check out "Good News / Bad News" on http://www.mythtv.org/
for a better understanding of Issac's current priorities. His
recent habits may not be typical of his behavior over the past
two years.

That said, I have been testing this afternoon and have found that
this does fix a specific problem that I have been seeing.

I have a few machines with SoundBlaster 16s (snd-ens1371) and
one with an SBLive! (snd-emu10k1). I've seen no negative effects
for playback with the patch on either of these SB models.

However, I've had problems where some recorded files recorded
on one of the machines sometimes cause "Audio buffer overflow,
audio data lost!" and no audio for the first 1 to 5 minutes then
may be out of sync and/or choppy after the audio starts. I had
one of these files on hand and was surprised to find that the
patched version played the audio from the beginning just fine
with no overflow messages.

I switched back and forth between patched and unpatched versions
and it was consistent that the patched version succeeded every
time and the unpatched version failed every time. I played the
same file from another SB16 and the SBLive! and got the same
result.

Further, it seemed to me that the audio was clearer and smoother
with better stereo separation but that may just be the placebo
effect ;-).

Audio buffering may or may not also affect A/V sync in the video
output loop but I don't think I'll delve deeply into that right
now. I did, however, watch news tickers and didn't see any new
or different behavior and jitterometer numbers were normal.

So, I can't say that the ioctls won't give bogus results on some
other cards or drivers or whatever but I can say this appears to
be a big win for the SoundBlaster cards that I can test.

--  bjm