[Sumover-tech] RAT - artifacts in sound output
p.ohanlon at cs.ucl.ac.uk
Sat Sep 4 16:02:17 BST 2010
It's not really worth spending any time on the OSS stuff as these days
it's mostly just provided by an emulation layer on top of the ALSA
drivers. Sorry haven't looked at the specific issue you pointed to
(I'm holiday right now). Try fixing it and see if works better...
It's tricky to know how to improve the RAT ALSA driver - I've poured
over various examples from others apps like Ekiga/mplayer etc but with
no big improvements so far... It would be nice if someone wrote some
decent docs for the ALSA subsystem.
On 3 September 2010 09:44, Linus Lüssing <linus.luessing at web.de> wrote:
> Okay, now that the alsa recording did not work at once, I tried
> some more with the OSS stuff. I would really like to get the 8kHz
> setting working because of the codecs with much lower bandwidth
> usage (and especially as 11/22/44kHz seem to work fine,
> it shouldn't be that difficult then, should it ;)?). The problem
> that I have with the 8kHz setting is, that I get about less than
> half a second of audio, then it stops for about half a second
> again - these inervals are quite random though.
> What I noticed at the sound test of OSS, 8kHz is, that I get
> _tons_ of "audio_read: Bad address" messages when debug-output
> enabled. So it looks like the read() command in oss_audio_read()
> is trying to store data at uninitilised memory pointed at by
> "u_char *buf", right?
> However, I found the parts of passing this buffer and the length
> for reading quite "confusing", there's quite some pointer fiddling
> in both transmit.c's tx_read_audio() and auddev.c's audio_read(),
> not making it very easy to track down a possible memory corruption
> Anyone having some more insights into this part of the code and
> some ideas what might cause the tons of "audio_read: Bad address"
> Cheers, Linus
> PS: See attachment of a debug-output-sample: Started RAT, 8kHz OSS
> was already selected, then just hit the audio test button for
> about 5 seconds and quit RAT again. I've chopped off about 2.5MB of
> these "audio_read: Bad address" messages at the inline-noted
> lines. The amount of these audio_read messages seems to correlate
> to the number of breaks in sound I heard during these ~5 seonds.
> Sumover-tech mailing list
> Sumover-tech at cs.ucl.ac.uk
More information about the Sumover-tech