Hi, Andres,

With further experimentation, I've found that the following  will 
work fine for my purposes in the XO-1/Sugar-on-a-Stick context:
-odac -+rtaudio=alsa -+rtmidi=alsa -M hw:1,0

Comments:
  Alsa is low-latency as is supported (to this date) on all XO and SoaS 
platforms.
  -odac refers indeed to the default plughw and makes the conversions you 
mention, at no apparent cost - whereas -odac:hw:0,0 does not. -odac will 
thus work as long as there is a single (usually the builtin) hardware 
device. This is something I can count on.
  -M hw:1,0 will work as long as only one controller is attached (which I 
can count on for my single-controller .csd's), and as long as any built-in 
MIDI interface (rare these days, as Peter pointed out) is not being used. I 
think I can count on MIDI being via USB. (If someone on the outside chance 
*did* want to use a builtin MIDI interface, he can change hw:1,0 to hw:0,0.)

So, the above will work in all usual configurations, as long as:
built-in audio is used;
one USB MIDI controller is used

For my multiple MIDI controller versions, these will use: -+rtmidi=alsa -Ma
as soon as Peter finds the time to incorporate your multi-controller patch.

Once this is achieved, all my issues are settled, and I'll be a "happy 
camper" (= find my joy).

Art Hunkins

----- Original Message ----- 
From: "Andres Cabrera" 
To: 
Sent: Monday, September 28, 2009 3:27 PM
Subject: [Csnd] Re: Re: Re: Getting around a (sound) device assignment 
problem in SoaS


Hi,

Since there's been no reply, I'll take a stab, but I may be compeltely 
wrong...

I think alsa names hw: real hardware devices. Hardware devices can be
constrained as to the number of channels or sample rates supported.
There might be software interfaces to these devices (like the alsa
"default" interface), which are plughw: devices, which can take care
of sample rate conversion and different number of channels. To
override the default settings, you would need to mess with the
.asounrc file, which I wouldn't recommend since it might take you a
while, as it is not very documented.

Cheers,
Andres

On Wed, Sep 23, 2009 at 9:41 PM, Art Hunkins  wrote:
> In starting down the road Victor suggests (and to solve the problem
> addressed in the subject), I immediately ran into an anomaly. I've no idea
> whether the issue is Csound's or Sugar/Linux.
>
> Description:
> In working with the XO-1, I settled on a stereo SR=32000. (This is the
> maximum SR I can use with my .csd's and get glitch-free sound on the 
> XO-1.)
>
> I developed all my work using the  -odac
>
> Faced with the fact of different device assignments with Sugar on a Stick
> (Soas) when MIDI controller(s) are inserted prior to boot, I need to check
> for other assignments for -odac, such as hw:1,0.
>
> Bottom line: -odac executed fine with SR=32000; -odac:hw:0,0 (its apparent
> equivalent) does not, *though it does fine with SR=44100!* The error 
> message
> is: Unable to set sample rate on soundcard. Failed to initialize real time
> audio output.
>
> Apparently there is a difference between 'plughw' (as -odac is referred to
> in my error log) and -odac:hw:0,0 (referred to as hw:0,0 in log).
>
> Linux folk: what is going on here? I need both to: 1) use SR=32000, and 2)
> test for different hardware device assignments - including -odac:hw:1,0 
> (it
> too doesn't like SR=32000).
>
> Art Hunkins
>
> ----- Original Message ----- From: "victor" 
> To: 
> Sent: Tuesday, September 22, 2009 3:52 AM
> Subject: [Csnd] Re: Getting around a (sound) device assignment problem in
> SoaS
>
>
>> The compile() function in the API (and in the csndsugui module) returns
>> 0 if successful and non-zero if not. You can check for this and recompile
>> with different options (etc) until it works.
>>
>> Victor
>>
>>
>> ----- Original Message ----- From: "Art Hunkins" 
>> To: 
>> Cc: 
>> Sent: Tuesday, September 22, 2009 4:03 AM
>> Subject: [Csnd] Getting around a (sound) device assignment problem in 
>> SoaS
>>
>>
>>> For SoaS (Fedora Linux), there remains a problem of device assignment
>>> involving audio out and MIDI in.
>>>
>>> Basically, if you boot SoaS *then* plug in a MIDI controller, audio is
>>> assigned C0D0; and MIDI, C1D0 (this is as expected). If you plug in a
>>> MIDI
>>> controller and then boot SoaS, MIDI gets C0D0 and audio C1D0 (this is
>>> *not*
>>> as expected!)
>>>
>>> The latter arrangement generates the following error message (in its 
>>> Log)
>>> when
>>> a script is run:
>>> Can't open device 'plughw' for audio output.
>>>
>>> It will be necessary to either do something either in Sugar, its Csound
>>> module, or in the python script that runs Csound to work with this 
>>> issue.
>>> So far, I've tried making manual changes to the file names (reflecting
>>> the "proper"
>>> device numbers, but the error remains.
>>>
>>> Suggestions? Especially from the Sugar side?
>>>
>>> It would seem that Sugar needs to
>>> look for and assign *audio* device numbers before *MIDI* device numbers.
>>> (Please
>>> note that this issue does *not* exist for the native XO-1. Perhaps
>>> snooping around
>>> in that code would be enlightening.) I'd appreciate the help; I'm
>>> absolutely lost here.
>>>
>>> Art Hunkins
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"=