Mailing List Archive

Doug Larrick wrote:

> On 11/30/03 18:56:35, Jason Hoos wrote:
>
>> I was testing out the original version of this patch, and I came
>> across a segfault.
>
>
> I'll take a look. Thanks.
>
>> P.S. Glad to hear the AC3 stuff works well on your system. Out of
>> curiosity, what kind of soundcard are you using?
>
>
> It's an intel8x0 (ac97) chipset with a C-Media CMI9739 codec, built
> into my motherboard. This codec annoys many under Linux for not
> actually having analog volume control in its mixer, but works fine
> for SPDIF under ALSA.

Can you post the modules.conf you're using for this chipset ? Never got
it to work on my computer...

--

peraage

> It's an intel8x0 (ac97) chipset with a C-Media CMI9739 codec, built
> into my motherboard. This codec annoys many under Linux for not
> actually having analog volume control in its mixer, but works
> fine for SPDIF under ALSA.

Thanks. I have another machine that might have a chip like this one on it
(not sure), I'll give it a try. Have you noticed any issues with audio
dropouts on your machine? I seem to only get the problem on certain
stations, particularly my local ABC affiliate (a 720p station). I don't
seem to get it on WGN (a 1080i station) though. And yet, if I play the
recorded files through mplayer, they work fine (last I checked anyways).
It's odd, and I'm wondering if the frame rate of the station has something
to do with it. I've only begun to dig through the AV sync code in Myth to
see if I can do something about it...

Jason

On 12/01/03 08:12:56, Per Åge Sørvik wrote:
> Can you post the modules.conf you're using for this chipset ? Never
> got it to work on my computer...

Here it is...

$ cat /etc/modutils/alsa
# This file was automatically generated by alsa-base's debconf stuff

alias char-major-116 snd
alias char-major-14 soundcore

options snd major=116 cards_limit=4

alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
alias /dev/dsp* snd-pcm-oss

alias snd-card-0 snd-intel8x0

alias snd-slot-0 snd-card-0
alias sound-slot-0 snd-slot-0

On 12/01/03 12:53:26, Jason Hoos wrote:

> Thanks. I have another machine that might have a chip like this one
> on it (not sure), I'll give it a try. Have you noticed any issues
> with audio dropouts on your machine?

I have not had any audio dropout issues, though I haven't watched any
720p recordings.

Does your receiver drop out of AC3 (back into PCM) when this happens?
If it does, I can see even a miniscule blip turning into something
annoying... it definitely takes mine half a second or so to re-start
AC3 after ff/rew

-Doug

> I have not had any audio dropout issues, though I haven't watched any
> 720p recordings.

It actually happens on live TV as well. Is the ABC affiliate by you a 720p
station? If so, does it seem to work well during live TV? (If there's no
720p station by you, would you be interested in testing a ~30-second clip if
I could manage to put one together?)

I've actually done some checking by putting a call into audiooutputalsa.cpp to
check how much of the sound card's buffer is full (something like
snd_pcm_avail_update() I think?), and the dropouts seem to correspond to
times when the buffer is mostly empty (which makes sense). It seems that the
decoder isn't keeping the buffer sufficiently full during playback, maybe
because it's a small buffer. I don't know what soundcards typically have for
buffer sizes; this one is apparently 64k (16384 frames) from what I can
tell...

> Does your receiver drop out of AC3 (back into PCM) when this happens?
> If it does, I can see even a miniscule blip turning into something
> annoying... it definitely takes mine half a second or so to re-start
> AC3 after ff/rew

It doesn't seem to. In any case I was having the problem before the AC3
patch; actually part of my motivation to get AC3 passthrough working was to
see if it would fix the problem. Oh well.

I'm in the process of getting the other machine set up, hopefully it'll work
better. Either that or I dive further into the playback stuff in Myth to see
if I can figure out what's happening...

Jason

On Tuesday 02 December 2003 02:07 am, Jason Hoos wrote:
> It actually happens on live TV as well. Is the ABC affiliate by you a 720p
> station? If so, does it seem to work well during live TV? (If there's
> no 720p station by you, would you be interested in testing a ~30-second
> clip if I could manage to put one together?)
>
> I've actually done some checking by putting a call into audiooutputalsa.cpp
> to check how much of the sound card's buffer is full (something like
> snd_pcm_avail_update() I think?), and the dropouts seem to correspond to
> times when the buffer is mostly empty (which makes sense). It seems that
> the decoder isn't keeping the buffer sufficiently full during playback,
> maybe because it's a small buffer. I don't know what soundcards typically
> have for buffer sizes; this one is apparently 64k (16384 frames) from what
> I can tell...

Tried turning on the 'Extra audio buffering' option in the playback settings
at all? It attempts to keep the audio buffer full.

Isaac

On 12/02/03 02:07:11, Jason Hoos wrote:

> It actually happens on live TV as well. Is the ABC affiliate by you
> a 720p station? If so, does it seem to work well during live TV?

I just watched 5 minutes or so of ABC (720p) and audio worked fine.

> I've actually done some checking by putting a call into
> audiooutputalsa.cpp to check how much of the sound card's buffer is
> full (something like snd_pcm_avail_update() I think?), and the
> dropouts seem to correspond to times when the buffer is mostly empty
> (which makes sense).

You're not seeing "Audio buffer overflow" messages or anything like
that, are you? I was having problems with OSS sound when I would watch
a 5.1-channel program (PBS mostly) that I diagnosed as a too-small
audio buffer in audiooutputoss. I would get overflow messages, and
eventually it would get lost and the audio would turn to white noise
(not pleasant). Tripling the OSS audio buffer size fixed it, though
since switching to ALSA fixed it I never cleaned it up & sent a patch.

It could also be that your ABC station's MPEG stream has the audio as
relatively large packets, relatively far apart. More overall buffering
(time delay) would help with that.

-Doug

> Tried turning on the 'Extra audio buffering' option in the
> playback settings
> at all? It attempts to keep the audio buffer full.

Yup. Didn't help. :( I played with various combinations of "Extra audio
buffering", "Aggressive sound card buffering", and "Experimental A/V" sync
to no avail (so far anyways). I will probably play with things more
tomorrow and do some more exhaustive testing; last time I played with it I
hit some point where things got thoroughly confused and it just quit working
completely, and I went to bed at that point rather than rebooting and
continuing...

Jason

> You're not seeing "Audio buffer overflow" messages or anything like
> that, are you? I was having problems with OSS sound when I
> would watch [...]

I got them occasionally, but not as frequently as the dropouts seemed to be
occuring. I have actually been playing with increasing the audio buffer
size in audiooutputalsa.cpp by adding a secondary buffer to stash more audio
samples outside the soundcard, but it didn't seem to be helping any, and
I've since lost that code.

> It could also be that your ABC station's MPEG stream has the audio as
> relatively large packets, relatively far apart. More overall buffering
> (time delay) would help with that.

Entirely possible. I was working on putting in some debugging output to see
how often audio packets were arriving, by putting some output in the
AddSamples method or somewhere thereabouts. I remember it seeming a bit
inconsistent, but I hadn't gotten to the point yet where I could correlate
the timings with the dropouts, never mind figuring out whether the
inconsistency is inherent in the stream or being introduced someplace else.
I'm going to keep playing and see what happens, especially since it does
seem to have something to do with this particular station.

For what it's worth this is all on an Athlon 3000, using XvMC for video on a
GeForce MX card, so I'm pretty sure that there's no lack of CPU cycles. :)
Anyhow I'm going to keep playing with it and see if I can get to the bottom
of things.

Jason