I neglected to mention perhaps the most important fact of all: with SoaS, any MIDI controller(s) must be plugged in AFTER boot and BEFORE compiling a .csnd. Users must be given explicit instruction to this effect.
Note that this limitation does not apply to the XO. My thoughts are: 1) Getting around this limitation is far more trouble that it's worth; 2) In the world of XO and Sugar-on-a-Stick a potential misunderstanding would arise rarely in any case. Art Hunkins ----- Original Message ----- From: "Art Hunkins" <abhun...@uncg.edu> To: <cso...@lists.bath.ac.uk> Cc: <pbrobin...@gmail.com> Sent: Monday, September 28, 2009 4:35 PM Subject: Re: [Csnd] Re: Re: Re: Getting around a (sound) device assignment problem in SoaS > Hi, Andres, > > With further experimentation, I've found that the following <CsOptions> > 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" <mantaray...@gmail.com> > To: <cso...@lists.bath.ac.uk> > 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 <abhun...@uncg.edu> 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 <CsOption> -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" <victor.lazzar...@nuim.ie> >> To: <cso...@lists.bath.ac.uk> >> 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" <abhun...@uncg.edu> >>> To: <sugar-devel@lists.sugarlabs.org> >>> Cc: <cso...@lists.bath.ac.uk> >>> 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 sy...@lists.bath.ac.uk with body >>>> "unsubscribe >>>> csound" >>> >>> >>> >>> Send bugs reports to this list. >>> To unsubscribe, send email sy...@lists.bath.ac.uk with body "unsubscribe >>> csound" >> >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sy...@lists.bath.ac.uk with body "unsubscribe >> csound" >> > > > > -- > > > Andrés > > > Send bugs reports to this list. > To unsubscribe, send email sy...@lists.bath.ac.uk with body "unsubscribe > csound"= _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel