[Sumover-tech] RAT - artifacts in sound output

[Jason Bell]

Linus

I would be interested to hear what the issues are.  As previously stated, I have found using ALSA Default devices causes audio artefacts, whereas using the same device name, but with ALSA 1 [device name], I have no issues.

I have no idea why this is the case, (and haven't dived into the code like you have), I just know how to work around it to fix it.

I would be keen to hear and possibly test any potential fixes for this problem.

Cheers,
Jason.


-----Original Message-----
From: sumover-tech-bounces at cs.ucl.ac.uk [mailto:sumover-tech-bounces at cs.ucl.ac.uk] On Behalf Of Linus Lüssing
Sent: Monday, 6 September 2010 10:33 PM
To: Piers O'Hanlon
Cc: sumover-tech at cs.ucl.ac.uk
Subject: Re: [Sumover-tech] RAT - artifacts in sound output

Hi Piers,

no worries, enjoy your holidays first please, don't wanna interrupt
that too much :). I couldn't get much further with the OSS stuff
for now either, so I gave the "Alsa 1: HDA Intel" another try,
which seemed to work best so far.
I noticed, that it's selecting "*audioInputPort: Front Mic Boost"
automatically. I then tried connecting a headset to the jacks and
hey the mic of that one works! And this is actually what I wanted to
get going in the end anyway, not using the the internal mic which
I did before for the testing :).
I first thought, that the Alsa driver would detect automatically,
if there is a mic plugged into the jack and if not, using the
internal one. But does not look like that though. Would having a
selectable mic-source in RAT's config menu make sense? (i.e. the
gnome-sound-recorder has that, too).

And despite from the internal mics not working, Alsa + RAT work
great now - no crackles, all sample rates working without noise or
breaks and the codec variety is awesome. So no hussle, let me know
after your holidays if you'd have any specific ideas what should
be tested, too or where you'd like to have some extra printfs in the
code to get the other bugs crunched :).

Cheers, Linus

On Sat, Sep 04, 2010 at 04:02:17PM +0100, Piers O'Hanlon wrote:
> Hi Linus,
> 
> 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.
> 
> Cheers,
> 
> Piers
> 
> 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
> > here.
> >
> > Anyone having some more insights into this part of the code and
> > some ideas what might cause the tons of "audio_read: Bad address"
> > messages?
> >
> > 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
> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-tech
> >
> >
> 

_______________________________________________
Sumover-tech mailing list
Sumover-tech at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-tech