[Sumover-tech] RAT - artifacts in sound output
p.ohanlon at cs.ucl.ac.uk
Tue Sep 7 10:11:48 BST 2010
The difference could be down to local ~/.asoundrc or /etc alsa init
scripts - There are a bunch of thing you can play with and configure.
E.g onl older Linux distro's they used to set up the default device
could be shared so they would run the dmix and dsnoop alsa plugins as
the 'default' device.
On 7 September 2010 05:07, Jason Bell <j.bell at cqu.edu.au> wrote:
> 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.
> -----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.
>> 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
More information about the Sumover-tech