[Sumover-tech] RAT - artifacts in sound output
todd.zimmerman at ubc.ca
Sat Sep 11 01:48:13 BST 2010
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
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',
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??
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
More information about the Sumover-tech