Hi Jean,

The AC'97 cards that are in the machines are only physically capable
of 48K i/o. Anything other than 48K is false economy, requiring
software resampling. 

Jonathan.

Jean Piché  writes:

> Hello all,
>
> We have a bit of a problem with audio on the OLPC (wiki.laptop.org)
> and wonder if some linux/alsa audio heads could help.
>
> We need to allow all audio apps on the machine to have access to
> ALSA, at the same time if necessary and at various sampling
> rates. Csound is the main audio engine on the machine but other apps
> do not use it (such as mp3 players etc.). The sound chip is an ADI1888
> that does not handle hw mixing. 
>
> We use Alsa  1.0.12 which includes the enabled dmix plugin, and our
> /etc/asound.conf file looks like this:
>
> pcm.!default { type plug  slave.pcm "dmix" } 
>
> This config routes all signals sent to alsa through the dmix
> plugin. That seems to work well with aplay. I can play many files at
> the same time all with different SRs without having to specify an
> explicit device in the command line such as:
>
> aplay test22.wav & aplay test16.wav & aplay test8.wav & aplay
> test44.wav
>
> etc...  works like a breeze.
>
> The problem:
>
> We use a 16k sampling rate for reasons. Using multiple instances of
> csound (see attached csd - csound 5.03) to do the same sort of mixing
> with dmix, there are two types of errors generated depending on the
> CsOptions:
>
> 1- options: -s 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac
>
> the first instance launches and performs fine csound  -r 16000 -k 50
> -+rtaudio=alsa -W -b512 -B1024 -odac dmixTest.csd & (background
> launch) launching a second instance generates an error csound  -r
> 16000   -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac dmixTest.csd
> error:  *** Cannot open device 'plughw' for audio output: Device or
> resource busy
>
> which seems to indicate that the default device (dmix in theory) is
> not being called.
>
> 2- options -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:default
>
> the first instance generates an error csound -r 16000 -k 50
> -+rtaudio=alsa -W -b512 -B1024 -odac:default Test.csd & (background
> launch) error:  ALSA: -b 512 not allowed on this device; use 341
> instead *** Error setting period time for real-time audio
>
> after which begins a wild goose chase of various -b and -B settings
> all end up in the same message
>
> 3-  options -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:dmix
> Test.csd & (background launch)
>
> etc, etc...  all different options give different errors
>
> The ONLY thing that seems to work is by using a SR of 48000 and
> standard size buffers. I  can then play multiple instance of csound.
>
> For CPU economy we need to run at 16k.  Dmix doesn't seem to be the
> issue. Sample rate and buffer size seem to be.
>
> Can anyone help with this thorny problem or are we up against
> somehting that cant be fixed?
>
> j
>
> here is the orc/sco:
>
> sr = 16000 ksmps = 50 nchnls = 1
>
> instr 1 ar oscil 10000,440,1 out ar endin
>
> f1 0 8192 10 1 i1 0 30
>
> _______________________ http://jeanpiche.com
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT Join
> SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys - and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> Csound-devel mailing list Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Jonathan,

Perhaps the goal here is to reduce the cost of operations other than the
delivery of samples to the DAC.  In this case, it is typically not a
false economy.  Run an arbitrarily high number of arbitrary DSP
algorithms at the same time and then mix - the 2/3 reduction in costs
will outweigh the modest costs of resampling.

Yours truly,
David

Jonathan Murphy wrote:
> Hi Jean,
> 
> The AC'97 cards that are in the machines are only physically capable
> of 48K i/o. Anything other than 48K is false economy, requiring
> software resampling. 
> 
> Jonathan.
> 
> Jean Piché  writes:
> 
>> Hello all,
>>
>> We have a bit of a problem with audio on the OLPC (wiki.laptop.org)
>> and wonder if some linux/alsa audio heads could help.
>>
>> We need to allow all audio apps on the machine to have access to
>> ALSA, at the same time if necessary and at various sampling
>> rates. Csound is the main audio engine on the machine but other apps
>> do not use it (such as mp3 players etc.). The sound chip is an ADI1888
>> that does not handle hw mixing. 
>>
>> We use Alsa  1.0.12 which includes the enabled dmix plugin, and our
>> /etc/asound.conf file looks like this:
>>
>> pcm.!default { type plug  slave.pcm "dmix" } 
>>
>> This config routes all signals sent to alsa through the dmix
>> plugin. That seems to work well with aplay. I can play many files at
>> the same time all with different SRs without having to specify an
>> explicit device in the command line such as:
>>
>> aplay test22.wav & aplay test16.wav & aplay test8.wav & aplay
>> test44.wav
>>
>> etc...  works like a breeze.
>>
>> The problem:
>>
>> We use a 16k sampling rate for reasons. Using multiple instances of
>> csound (see attached csd - csound 5.03) to do the same sort of mixing
>> with dmix, there are two types of errors generated depending on the
>> CsOptions:
>>
>> 1- options: -s 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac
>>
>> the first instance launches and performs fine csound  -r 16000 -k 50
>> -+rtaudio=alsa -W -b512 -B1024 -odac dmixTest.csd & (background
>> launch) launching a second instance generates an error csound  -r
>> 16000   -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac dmixTest.csd
>> error:  *** Cannot open device 'plughw' for audio output: Device or
>> resource busy
>>
>> which seems to indicate that the default device (dmix in theory) is
>> not being called.
>>
>> 2- options -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:default
>>
>> the first instance generates an error csound -r 16000 -k 50
>> -+rtaudio=alsa -W -b512 -B1024 -odac:default Test.csd & (background
>> launch) error:  ALSA: -b 512 not allowed on this device; use 341
>> instead *** Error setting period time for real-time audio
>>
>> after which begins a wild goose chase of various -b and -B settings
>> all end up in the same message
>>
>> 3-  options -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:dmix
>> Test.csd & (background launch)
>>
>> etc, etc...  all different options give different errors
>>
>> The ONLY thing that seems to work is by using a SR of 48000 and
>> standard size buffers. I  can then play multiple instance of csound.
>>
>> For CPU economy we need to run at 16k.  Dmix doesn't seem to be the
>> issue. Sample rate and buffer size seem to be.
>>
>> Can anyone help with this thorny problem or are we up against
>> somehting that cant be fixed?
>>
>> j
>>
>> here is the orc/sco:
>>
>> sr = 16000 ksmps = 50 nchnls = 1
>>
>> instr 1 ar oscil 10000,440,1 out ar endin
>>
>> f1 0 8192 10 1 i1 0 30
>>
>> _______________________ http://jeanpiche.com
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT Join
>> SourceForge.net's Techsay panel and you'll get the chance to share
>> your opinions on IT & business topics through brief surveys - and earn
>> cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
>> Csound-devel mailing list Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Jean Piché wrote:

> We have a bit of a problem with audio on the OLPC (wiki.laptop.org)  
> and wonder if some linux/alsa audio heads could help.

Firstly, the linux-audio-dev mailing list may be more appropraite
for this quetion.

> We need to allow all audio apps on the machine to have access to  
> ALSA, at the same time if necessary and at various sampling rates.  
> Csound is the main audio engine on the machine but other apps do not  
> use it (such as mp3 players etc.). The sound chip is an ADI1888 that  
> does not handle hw mixing.
> 
> We use Alsa  1.0.12 which includes the enabled dmix plugin, and our / 
> etc/asound.conf file looks like this:

Sorry, ALSA's Dmix has some real problems.

> 	error:  *** Cannot open device 'plughw' for audio output: Device or  
> resource busy
> 
> which seems to indicate that the default device (dmix in theory) is  
> not being called.

Even if you have Dmix enabled, all applications still need to agree
to use dmix rather than plughw. It looks like Csound by default tries 
to use plughw.

I know its possibly not what you want to hear, but in the future, the
best solution will be to replace alsa/dmix with PulseAudio:

   http://www.pulseaudio.org/

which acts as a sound server allowing multiple applications to access
a single audio device.

Unfortunately PulseAudio is not quite ready yet.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"I do have a policy of mandatory evisceration where the crime of 
whitespace in filenames is perpetrated on my systems. This has
inspired a new range of designer colostomy bag covers in corduroy,
velvet, and the ever popular denim."
-- jdub on the SLUG mailing list

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Firstly, the linux-audio-dev mailing list may be more appropraite
> for this quetion.

Will do this indeed. Thanks.

>> We need to allow all audio apps on the machine to have access to
>> ALSA, at the same time if necessary and at various sampling rates.
>> Csound is the main audio engine on the machine but other apps do not
>> use it (such as mp3 players etc.). The sound chip is an ADI1888 that
>> does not handle hw mixing.
>>
>> We use Alsa  1.0.12 which includes the enabled dmix plugin, and our /
>> etc/asound.conf file looks like this:
>
> Sorry, ALSA's Dmix has some real problems.

Given some grumbles on Dmix in general, that is what I initially  
thought, until I successfully ran 4 instances of aplay at different  
SRs. Same with mp3play. And running multiple instances of csound at  
48k sr also works very well through Dmix (my post was not clear on  
that). A cursory research on "Alsa Dmix" in csound list archives did  
raise some cases of difficulties with block sizes ( -b -B ) but  
nothing conclusive. It does suggest that the problem might be on  
csound's side.

>> 	error:  *** Cannot open device 'plughw' for audio output: Device or
>> resource busy
>>
>> which seems to indicate that the default device (dmix in theory) is
>> not being called.
>
> Even if you have Dmix enabled, all applications still need to agree
> to use dmix rather than plughw. It looks like Csound by default tries
> to use plughw.

  Csound does see Dmix as the default output when -odac is used  
alone. I was just trying every variation I could think of.

> I know its possibly not what you want to hear, but in the future, the
> best solution will be to replace alsa/dmix with PulseAudio:
>
>    http://www.pulseaudio.org/
>
> which acts as a sound server allowing multiple applications to access
> a single audio device.
>
> Unfortunately PulseAudio is not quite ready yet.

I have looked at PulseAudio and I will enquire some more but it may  
be overkill for what we want to acheive.



j




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Ogborn  writes:

> Perhaps the goal here is to reduce the cost of operations other than the
> delivery of samples to the DAC.  In this case, it is typically not a
> false economy.  Run an arbitrarily high number of arbitrary DSP
> algorithms at the same time and then mix - the 2/3 reduction in costs
> will outweigh the modest costs of resampling.
>
> Yours truly,
> David

Thanks David, I (obviously) wasn't aware of that. 

Jean, sorry about the abrupt post this morning (morning for me at any
rate). I was on my way to work and just wanted to point out the most
obvious problem as I saw it.

I'm lucky enough (lol) to have a 4 year old AC'97 card in my
laptop. Until last August it was the only card I had access to, so for
the most part I'm quite familiar with the trials and tribulations
involved in getting them to do what you want. The following
information from the alsa wiki (just google dmix, it should be the
first available link):

NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix
is enabled as default for soundcards which don't support hw mixing.

lead me to believe that instead of using an /etc/asound.conf which
sets up dmix, you can just use something like this (for my card):

        pcm.ali5451 {
           type hw
           card 0
        }

        ctl.ali5451 {
           type hw
           card 0
        }

I had a look at the ALSA soundcard matrix, and wasn't sure what module
you would be using. What does lsmod give?

FWIW, I'm able to run several instances of the example instrument that
you posted, like so:



-+rtaudio=alsa -odac -d -m0




  sr	    =  16000
  ksmps	    =  50
  nchnls    =  1

    instr 1

  ar	    oscil     10000, 440, 1

	    out	      ar 

    endin

 


f1 0 8192 10 1 
i1 0 30
e



without any problems. Obviously my processor is a bit more powerful
than the OLPC machines, but I'm sure that what David says is true, and
that those were your "reasons" for using sr = 16000. Perhaps you could
try changing /etc/asound.conf to something similar to the above?

Hope that this helps,
Jonathan.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven,

Am I (as per usual) missing something vital in my understanding of the
following:

"NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix
is enabled as default for soundcards which don't support hw mixing."
 
as meaning that a .asoundrc file like the one that you've posted is
actually uneccesary? I don't mean that the file itself is unecessary,
just that explaining to alsa how to do something that it is supposedly
already doing (and as the /etc/asound.conf file that I posted earlier
works in terms of not only being able to play numerous samples using
aplay but also, and simultaneously, the Csound instances that Jean was
attempting to run, actually doing)? 

If I'm not speaking gibberish perhaps you could also try using the
default .asoundrc or /etc/asound.conf for your card?

Jonathan.

"Steven Yi"  writes:

> Hi Jean,
>
> WIth some experimentation, I'm seeing that the suggested rate given
> back by Csound is always related to the buffer and period size of
> dmix.  In my .asoundrc I have:
>
> pcm.amix {
>     type dmix
>     ipc_key 50557
>     slave {
>         pcm "hw:0,0"
>         period_time 0
>         period_size 1024
>         buffer_size 8192
>         format S32_LE
>     }
>     bindings {
>         0 0
>         1 1
>     }
> }
>
> # route ALSA software through pcm.amix
> pcm.!default {
>     type plug
>     slave.pcm "amix"
> }
>
> So 8192 is the buffer size I have set which I think is the default.
> Now, if I use 16000, that's 1/3 of 48000, and the suggested values I
> get from Csound loook to be consistently 1/3 of the period and 1/3 of
> the buffer size of sizes set for dmix.  The 1/3 is not rounding quite
> right, but if I use sr 24000, It'll suggest 512 and 4096, which seem
> to work.
>
> Could you try either using 24000 if that's not too much for CPU, or
> changing the asoundrc period and buffer size to something that is
> easily divislble by 3 if using 16000?
>
> steven
>
>
> On 1/17/07, Jean Piché  wrote:
>>
>>
>>
>> Hello all,
>>
>> We have a bit of a problem with audio on the OLPC (wiki.laptop.org) and
>> wonder if some linux/alsa audio heads could help.
>>
>> We need to allow all audio apps on the machine to have access to ALSA, at
>> the same time if necessary and at various sampling rates. Csound is the main
>> audio engine on the machine but other apps do not use it (such as mp3
>> players etc.). The sound chip is an ADI1888 that does not handle hw mixing.
>>
>> We use Alsa  1.0.12 which includes the enabled dmix plugin, and our
>> /etc/asound.conf file looks like this:
>>
>> pcm.!default {
>>  type plug
>>  slave.pcm "dmix"
>> }
>>
>> This config routes all signals sent to alsa through the dmix plugin. That
>> seems to work well with aplay. I can play many files at the same time all
>> with different SRs without having to specify an explicit device in the
>> command line such as:
>>
>> aplay test22.wav &
>> aplay test16.wav &
>> aplay test8.wav &
>> aplay test44.wav
>>
>> etc...  works like a breeze.
>>
>> The problem:
>>
>> We use a 16k sampling rate for reasons. Using multiple instances of csound
>> (see attached csd - csound 5.03) to do the same sort of mixing with dmix,
>> there are two types of errors generated depending on the CsOptions:
>>
>>
>> 1- options: -s 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac
>>
>>  the first instance launches and performs fine
>> csound  -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac dmixTest.csd &
>> (background launch)
>>  launching a second instance generates an error
>> csound  -r 16000   -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac dmixTest.csd
>>  error:  *** Cannot open device 'plughw' for audio output: Device or
>> resource busy
>>
>> which seems to indicate that the default device (dmix in theory) is not
>> being called.
>>
>>
>> 2- options -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:default
>>
>>  the first instance generates an error
>> csound -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:default Test.csd
>> & (background launch)
>>  error:  ALSA: -b 512 not allowed on this device; use 341 instead
>>  *** Error setting period time for real-time audio
>>
>> after which begins a wild goose chase of various -b and -B settings all end
>> up in the same message
>>
>> 3-  options -r 16000 -k 50 -+rtaudio=alsa -W -b512 -B1024 -odac:dmix
>> Test.csd & (background launch)
>>
>>
>> etc, etc...  all different options give different errors
>>
>>
>>
>> The ONLY thing that seems to work is by using a SR of 48000 and standard
>> size buffers. I  can then play multiple instance of csound.
>>
>> For CPU economy we need to run at 16k.
>> Dmix doesn't seem to be the issue. Sample rate and buffer size seem to be.
>>
>> Can anyone help with this thorny problem or are we up against somehting that
>> cant be fixed?
>>
>>
>> j
>>
>>
>>
>>
>> here is the orc/sco:
>>
>> sr = 16000
>> ksmps = 50
>> nchnls = 1
>>
>> instr 1
>> ar oscil 10000,440,1
>> out ar
>> endin
>>
>>
>> f1 0 8192 10 1
>> i1 0 30
>>
>>
>>
>>
>>
>> _______________________
>> http://jeanpiche.com
>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

PS: By "default" I didn't mean anything that is actually set up by
default, I meant the suggested .asoundrc setup as described in the
soundcard matrix for your card. 

J.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven,

> I'm not completely sure about everything asoundrc related,

Neither am I.

> but I think the one you posted gives an alias to the hw cards, but
> the default is still dmix because you don't have a definition for
> routing default (I think...).

But that was my point. It's unecessary to enable something that's
enabled by default, and I think that it might be what's causing the
problem.

> If there's only one soundcard on the computer, then you probably can
> just set it once in an /etc/asoundrc file and forget it.

You can definitely do that, and in fact if you define your usb device
like so:

        pcm.usb-audio {
           type hw
           card 1
        }

        ctl.usb-audio {
           type hw
           card 1
        }

as your second card, then the problem that you describe (assuming that
your usb device is standards compliant, and that you don't have to
load any firmware to initialise it) should disappear. This is what the
file is designed to do, and in my experience it works. The only gotcha
is where you have more than one device using the same module, in which
case you need to name them rather than just number them.

I have the simplest possible /etc/asound.conf (my other card is
firewire, using freebob not alsa), and I cannot replicate the problem
that you and Jean describe. I am almost certain that dmix
configuration is actually unecessary, and is probably causing the
problem. I strongly recommend that both yourself and Jean try the
configuration that I've described. If I'm wrong, I'm prepared to eat
humble pie. Done it many times before. NB. The AC'97 chipset needs to
have the alsa-driver source code stay on file in the same spot from
where it was compiled. I have no idea why this is the case, it's a bug
that I've learnt to live with. If you see boot warnings re AC'97,
that's probably the problem, and is likely the reason for the modem
etc screwing with your usb device.

Jonathan.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven,

> For my computer, dmix routes to whatever device happens to be assigned
> hw0:0 first. Sometimes that's the USB device and sometimes that the
> onboard soundcard.  If I don't explicitly assign it to the hardware
> number of the USB device, I can't get predictable results.

Sorry, now I understand your situation. However, with regard to the
OLPC project, as there is only one soundcard, would it not be best to
just create the alias? Dmix will be enabled by default for the card,
and using that setup the problems that Jean described are not arising
for me. 

> What settings are you using for your testing with Csound?  (-b, -B,
> sr, -o)

Here is the .csd that I am using, the settings are all in the
CsOptions, I'm just opening up several xterms and running "csound
olpc.csd", "aplay foo41.wav", "aplay foo48.wav" and so on. 



-+rtaudio=alsa -odac -d -m0 -b512 -B1024




  sr	    =  16000
  ksmps	    =  50
  nchnls    =  1

    instr 1

  ar	    oscil     10000, 440, 1

	    out	      ar 

    endin

 


f1 0 8192 10 1 
i1 0 30
e



Jonathan.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven and List,

I'm very sorry. I've eaten humble pie for dinner and will wear my
conical hat with the letter "D" on it to work for the next year. I
will also write an opcode that prints "I must not write to the lists
unless I know what I'm talking about." in 101 different languages. It
will be a private opcode and I will not insist on inclusion in the
Canonical language. Seriously, I'm sorry to have wasted your time.

Jonathan.

"Steven Yi"  writes:

> Hi Jonathan,
>
> I just noticed from your other email:
>
>        pcm.ali5451 {
>           type hw
>           card 0
>        }
>
>        ctl.ali5451 {
>           type hw
>           card 0
>        }
>
> If this is the card you are testing with, I took a look at the ALSA
> soundcard matrix page and it lists the ALI5451 as supporting Hardware
> Mixing, which is not the case for Jean or myself. I'm assuming that is
> the difference between what you are finding and what we are finding.
>
> steven

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven,

Thanks for your patience and forbearance.

> BTW: Should I write something about this in the manual?

I've been thinking about this kind of thing a lot lately. When I first
started to use Csound, sometime late 2005, there was little online
information regarding installation of Csound5 on Linux. There was a
great article by Dave Phillips, but the focus was primarily on new
features, rather than on how to get things working. If nothing else, I'm
stubborn, so I googled for a week or so and managed to compile from
CVS, and promptly wrote a brief howto on the Csound5 forums page. For
a while, it was quite popular, and people wrote in regarding
problems/complications. I was watching the post, and so was Istvan, so
by and large readers got informed (Istvan) and simple (self)
explanations. The major problem was that it was geared towards
then current versions of software such as alsa, jack, python,
fluidsynth, and also particular distributions (at the time I was using
Ubuntu, Istvan was using Planet CCRMA). Eventually it disappeared
(which is good). The thing is, although I no longer use Ubuntu, nor
(for that matter) any of the mainstream Linux distributions, I still
use csound5 CVS, and install it in much the same manner described, and
the bare bones of the installation method still apply. The core of
that experience could have been retained, and would still prove useful
to others.

It seems to me that the Canonical Csound Reference Manual should deal
primarily with the aspects of Csound that change relatively rarely. It
should be as Canonical as possible. Installation and configuration
instructions for the various platforms will change rapidly, and are
only ever going to be a major PITA for developers in general and
Andres in particular, if they are to be constantly updated in the
manual. Every couple of days someone is going to write to the user
list saying "I followed the instructions to the letter but blah isn't
working." The rate of change of the manual is not such that it can
keep pace with the change in development of every strand of every
platform that Csound can be compiled upon, and it should not be
expected to be able to do so.

On the other hand, the wiki can, and is in fact specifically designed
to be able to do this sort of thing. If someone finds that information
is outdated, they can simply change it, or add a note to the effect
that "I tried this but foobar.deb is no longer available. I had to do
this to get things working." If a developer or experienced Csounder
was the original author of the page in question, this would improve
things hundredfold. They could subscribe to the page (all you need to
do is click on a button), then when any changes to the page are made,
they will be notified via email, and they can check the veracity of
the information, add notes as required and so on, all this without the
requirement of any party having CVS write access. The wiki has the
potential to harness all of the energy of all of the people who use
Csound, not just the developers, who (I imagine) are already
overextended by their jobs, musical output, relationships and so
forth. If it reaches a certain critical mass, then it will become
almost self-maintaining. As an example of this possibility, although
not a Csound developer, nor associated with the OLPC project, I have
just added a link to the Csound page on the OLPC Wiki on the
CsoundWiki. 

http://tobiah.org/csoundwiki/ExternalLinks#head-b232301da10556a7340c794705628f4139a59aec

Anyone with an interest in these projects could have done so, provided
that they have internet access and a browser. On the other hand, if
someone had wanted to add similar information to the manual (from the
above it should be apparent that I don't think it would necessarily be
a good idea), they would have either had to have had CVS write access,
or written persuasively to one of the lists. The wiki is a fluid
informatic zone, with enormous potential. The manual is by comparison
static, but this is precisely the task of a manual, except when new
circumstances arise, or it is generally recognised that an
improvement be made.

When Mike posted to the user list saying that he was going to write up
his experiences and suggestions regarding compiling Csound on Ubuntu,
and add them to the manual, my feelings were mixed, as follows:

1. Fantastic. I admire, respect, and seek to emulate the dedication
   of (all) developers, (but) particularly when they take the time to
   provide documentation for newcomers.

2. That's exactly what I did a year and a half ago, and I found that
   it needed to be updated every couple of weeks, as the distribution
   packages changed. I tried to do this, but found that other tasks
   were more pressing, and that I was unable to do so.

3. I really hope that he puts it up on the wiki instead.

The wiki really needs the support of Csound developers. The wiki
format is particularly good for some kinds of information, such as
that which you have provided regarding dmix. I know that you will do
as you think best, and that is one of the reasons that you have my
utmost respect. The foregoing is merely my opinion regarding desirable
methods for propagating differing types of information.

Sincerely,
Jonathan.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

PostScript:

About a week after I first managed to install Csound5, I was among the
20 or so lucky people at the Kingston (Onatario) Tone Deaf Festival
witnessing a dazzling multimedia display by Jean Piche. It was
immensely inspiring, and one of the major reasons why I persisted
with something that was otherwise scarcely comprehensible.  

Thankyou for that Jean, the "Voyage through India (can't remember the
actual title)" is especially memorable.

Jonathan.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net