[Sumover-tech] RAT - artifacts in sound output

[Todd Zimmerman]

On 09/07/2010 02:11 AM, Piers O'Hanlon wrote:
> Hi Jason,
>
> 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 that note, why doesn't rat honour my .RATdefaults audioDevice 
selection when starting it from within AG? Here is the behaviour I'm seeing:

1. set *audioDevice: ALSA 1: AK4571 in .RATdefaults
2. start rat from the command line
3. rat starts with ALSA 1: AK4571 properly set as the device.

BUT, using the same .RATdefaults file, starting from within an 
audioservice in AG, it uses "ALSA default: AK4571" - which is really a 
pain.

I did some debugging, and within the AudioService.py file, it opens the 
.RATdefaults file properly and in fact if I log the ratDefaults entries 
it found within that file (from within AG), the proper ALSA 1: AK4571 
setting is found within the file.  So I know AG can see the setting....

Further, from what I see rat is just called with:

options = ['-C', u'WestGrid_VenueServer_Lobby', '-S', 
'7f0000012d69768bddb4f409cc6e10a5', '-f', 'L16-16K-Mono', '-t', '127', 
u'233.59.192.2/60500']

so, standard command line rat options....

Is setting these options making it ignore the .RATdefaults file?  Or is 
it a pathing issue that is causing it to not find my .RATdefaults??

Any thoughts?

Todd

-- 
Collaboration & Visualization Specialist
UBC Okanagan ITServices - http://web.ubc.ca/okanagan/itservices/
WestGrid - http://www.westgrid.ca
Compute Canada - http://computecanada.org
Todd Zimmerman | 250.807.9979 | todd.zimmerman at ubc.ca