[AG-TECH] Echoing and choppy audio on Mac to Mac

Tue Nov 25 03:56:56 CST 2008

G'day Piers, Gurcharan and all

I have been meaning to respond to this email all day, but unfortunately
I have been tired up with a number of other things.

I have helped to organise a colleague in Australia who is currently
looking into fixing the mac Audio issue.  This colleague has only just
started (began a couple of weeks ago) and is actually doing this on his
own personal time.  He has a fair bit of experience with mac audio and
has assisted to port other cross platform apps to the mac.

Due to the fact that he is working on this during his own personal time,
he only has a limited time to work on this, but is committed to fixing
the issue and excited to be working on this project.  Obviously, if
anyone has resources and would like to be involved, he would be happy to
collaborate.

So, I can say that someone in Australia is actively working on this
issue and I will endeavour to keep the AG community updated with any
future progress.  Unfortunately there is not much else to tell at the
moment, but I too would like to see this issue resolved ASAP.

Cheers,
Jason.

-----Original Message-----
From: Piers O'Hanlon [mailto:p.ohanlon at cs.ucl.ac.uk] 
Sent: Tuesday, 25 November 2008 7:20 PM
To: gurcharan.khanna at rit.edu; Jeremy Mann; Brad Knowles
Cc: Christoph Willing; ag-tech at mcs.anl.gov
Subject: Re: [AG-TECH] Echoing and choppy audio on Mac to Mac

Hi,

As mentioned the problem with RAT audio on OSX is known. Firstly it is
unfortunately an intermittent problem that not every mac user seems to
experience - though a significant number of people are seeing it. This
means it's more difficult to nail down the bug straight away - it's
not just a crash when someone does X.

Secondly given RAT/RAT are open source we try to encourage wider
participation in the development process - as there are not enough
resources to fix every problem. Subsequently when we get offers from
to do work it is good to give those parties a chance to do the work -
even if in some cases it means that the fix is a bit longer coming
than it might otherwise be.

On this specific issue we have had a few offers to fix it over that
last year or so but although work was done unfortunately they did not
ultimately result in a satisfactory fix. We do have another an offer
to fix it under way and are seeing how this comes along. If this
doesn't bear fruit we will fix it.

Basically what there are two approaches; Fix the existing driver - so
it doesn't drift over time and  so it can support higher sample rates
- unfortunately  the code is quite old and was written for OSX 10.1 -
and now doesn't compile using the latest Xcode on Leopard (though it
does run albeit with problems). The second option, which is more
preferable, but requires more resources, is to re-write the driver
using newer Apple's Core Audio API make sure its design fixes the
current problems. We are maintaining the current state on the driver
developments here:
https://frostie.cs.ucl.ac.uk/nets/mmedia/ticket/180

Cheers,

Piers.

2008/11/25 Gurcharan S. Khanna <gskpop at cis.rit.edu>:
> chris,
>
> i wonder if it could be spec'd out in terms of full-time work. it's so
> annoying and would
> be so beneficial i feel like committing resources to getting it done
but i
> need some definite
> parameters to be successful. how many hours do you think it would take
to
> complete? and
> if it's already started by someone, would a different effort be
redundant?
>
> -gurcharan
>
> Christoph Willing wrote:
>>
>> On 25/11/2008, at 2:47 PM, Gurcharan S. Khanna wrote:
>>
>>> chris,
>>>
>>> is the fix known and it's just a matter of devoting resources to it?
>>> or is the fix still something difficult that has to be figured out?
>>
>> Gurcharan,
>>
>> I believe the fix is reasonably, if not completely, understood. It
now
>> needs resources to actually be done. I understand someone has just
started
>> some work on it in the last week or so. However I think that it will
be
>> worked on as a spare time project, rather than full time, so it may
still be
>> a while before we see any results.
>>
>>
>> chris
>>
>>
>>> Christoph Willing wrote:
>>>>
>>>> On 25/11/2008, at 8:34 AM, Jeremy Mann wrote:
>>>>
>>>>> On Mon, Nov 24, 2008 at 4:30 PM, Christoph Willing
>>>>> <c.willing at uq.edu.au> wrote:
>>>>>>
>>>>>> On 25/11/2008, at 5:58 AM, Brad Knowles wrote:
>>>>>>
>>>>>>> Jeremy Mann wrote:
>>>>>>>
>>>>>>>> I encountered my first problem when connecting two Mac 10.5
Leopard
>>>>>>>> machines using the Beta 3.2 version. Audio is good for about 2
>>>>>>>> minutes, then it sounds like the other person is underwater and
>>>>>>>> contains an echo. On his end, my audio sounded fine. No codecs
were
>>>>>>>> changed and we even tried different bridges, all had the same
>>>>>>>> problem.
>>>>>>>> Could this be a network configuration problem at his
University?
>>>>>>>
>>>>>>> My understanding is that this is a known problem with "rat" on
Mac OS
>>>>>>> X,
>>>>>>> or at least Mac OS X on Intel hardware.
>>>>>>>
>>>>>>> So far, the only solution that has been offered to me is to quit
and
>>>>>>> restart the client every few minutes.
>>>>>>
>>>>>>
>>>>>> Rather than completely quitting then restarting, its enough to
toggle
>>>>>> the
>>>>>> audio icon near the top of the VenueClient gui.
>>>>>
>>>>> I guess the next question would be, HOW would he know his audio is
>>>>> choppy? On his end, incoming audio sounds fine, so how would he
know
>>>>> to toggle the GUI switch or restart the RAT client without asking
>>>>> somebody if his speech was choppy?
>>>>
>>>> Yes, its not a great workaround - we really need a proper fix. I
think
>>>> the Mac user would have to do the toggle just before they're about
to speak
>>>> and/or just toggle every 2 minutes or so.
>>>>
>>>>
>>>> chris
>>>>
>>>>
>>>>
>>>> Christoph Willing                       +61 7 3365 8350
>>>> QCIF Access Grid Manager
>>>> University of Queensland
>>>>
>>>
>>>
>>> --
>>> -------------------------
>>> Gurcharan S. Khanna, Ph.D.
>>> Director of Research Computing
>>> Office of the Vice President for Research
>>> http://rc.rit.edu
>>>
>>> Assistant Research Professor, Ph.D. Program
>>> Golisano College of Computing and Information Sciences
>>> http://people.rit.edu/gskpop
>>>
>>> Director, Interactive Collaboration Environments Laboratory,
>>> Center for the Advancing the Study of Cyberinfrastructure
>>> http://icelab.rit.edu
>>> ---
>>> Rochester Institute of Technology
>>> 1 Lomb Memorial Drive
>>> Rochester, New York 14623-5603
>>> Phone: 585-475-7504  ~  Cell: 585-451-8370
>>> Email: gurcharan.khanna at rit.edu
>>>
>>
>> Christoph Willing                       +61 7 3365 8350
>> QCIF Access Grid Manager
>> University of Queensland
>>
>
>
> --
> -------------------------
> Gurcharan S. Khanna, Ph.D.
> Director of Research Computing
> Office of the Vice President for Research
> http://rc.rit.edu
>
> Assistant Research Professor, Ph.D. Program
> Golisano College of Computing and Information Sciences
> http://people.rit.edu/gskpop
>
> Director, Interactive Collaboration Environments Laboratory,
> Center for the Advancing the Study of Cyberinfrastructure
> http://icelab.rit.edu
> ---
> Rochester Institute of Technology
> 1 Lomb Memorial Drive
> Rochester, New York 14623-5603
> Phone: 585-475-7504  ~  Cell: 585-451-8370
> Email: gurcharan.khanna at rit.edu
>
>