[Sumover-tech] RAT corrupt sound

[Jason Bell]

As a thought, could you try using a different audio device.

For example, I use “ALSA 1: Chat 150”, rather than the default device “ALSA Default: Chat 150”, as using the Default device causes me corrupt audio.

Does this have any effect in the issues you are seeing ???

I have seen lots of issues using the default device and maybe the work you have done below might suggest a possible fix.  I would be interested to hear more.

Regards,
Jason.

From: sumover-tech-bounces at cs.ucl.ac.uk [mailto:sumover-tech-bounces at cs.ucl.ac.uk] On Behalf Of ?????? ??????
Sent: Friday, 12 November 2010 08:03 PM
To: sumover-tech at cs.ucl.ac.uk
Subject: [Sumover-tech] RAT corrupt sound

Hello all!

I have a problem with RAT on Fedora 11, 12. Received sound has a lot
of jamming what sounds like ugly electronic noise. I try to solve this
problem by myself since may of 2010, and I found some solution but
still not found problem source and cannot fix it but lower sound
corruption. I interesting only 48kHz Mono mode, btw. How can I fix it?
First, I checkout latest version of RAT from repository and build a
debug version of common lib and rat itself. And first thing what I
find is horrible spamming of message:

RTP packet queue overflow.

So I just enlarge a little this queue. Sound become slightly better.
Next my target was find why messages

Insert X samples.
Playout buffer shift back X samples.

occurs and sound has jamming and flipping. I find out what it cause
because there is some unsynchronization detecte in function

int source_check_buffering(source *src) in file source.c

I have no idea why it does. And I don't know how to debug it. Hardware
problem? Software? ALSA? No idea. Then I go to the ALSA settings and
starts an experiments to configure default ALSA device. And I find a
configuration what almost do a sound well!! So there it is:

1) I add .asoundrc file in my home directory:
defaults.ctl.!card Intel
defaults.pcm.!card Intel

defaults.pcm.dmix.!rate 48000
defaults.pcm.dmix.!format S16_LE

2) And, important, I manually setup buffers sizes for default ALSA
device directly in dsnoop.conf and dmix.conf. And channel count and
binding also. There it is:

I add to dsnoop.conf:

channels 2
period_time 10000
periods 16
bindings.0 0
(very  short fragments)

And to dmix.conf:

channels 1
period_time 300000
periods 16
(laaaarge fragments)

And VOILA! sound become clean and very good ... almost. Once-twice in
5 min interval randomly occurs same flips and messages:

Insert X samples.
Playout buffer shift back X samples.

That is my story. If some one know this problem and know how to debug
and fix it, lets discuss! Also, I can send my hardware and software
configuration if needed.

And at last, I wrote some CLI interface to RAT what useful when RAT
work in -noui mode and I can share it if some one interested about it
:) Its not perfect may be because I have no one friend who understand
the mbus and RAT :) But it works.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/sumover-tech/attachments/20101115/7bf7d673/attachment.html