Steven Yi wrote:

> I recently updated to Fedora Core 4 and with that upgraded my ALSA
> libs to 1.0.9 (was previously using 1.0.6).  It seems that now I am
> unable to use -+rtaudio=alsa as Csound will fail with:
> 
>  *** Failed while trying to set soundcard DMA buffer size
> Failed to initialise real time audio output
> 
> I have -b64 -B256 set, using --expression-opt and -m0 -d normally.  My
> settings all worked before switching to FC4 and the new alsa libs. 
> The Portaudio plugin seems to work alright, but would rather prefer to
> use the ALSA plugin. I've tried various combinations of -b and -B as
> well, without much luck.

I only have ALSA 1.0.6 at this time, so some system upgrade is needed
to have an attempt at fixing this problem, unless there was an obvious
incompatible change in the ALSA API that broke the code below:

     /* buffer size, */
     if (dev->buffer_smps == 0) dev->buffer_smps = 1024;
     if (dev->buffer_smps < 64) dev->buffer_smps = 64;
     if (snd_pcm_hw_params_set_buffer_size(dev->handle, hw_params,
                                           (snd_pcm_uframes_t) dev->buffer_smps)
         < 0) {
       sprintf(msg, " *** Failed while trying to set soundcard "
                    "DMA buffer size\n");
       goto err_return_msg;
     }

By the way, did you try using different device names ? Does the error
occur with all devices, and using any sample rate and number of channels ?


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Greetings:

  I must note that I had a world of problems with ALSA 1.0.9 + kernel 
2.6.12. Steven, are you using a package-based distro ? Does your sound 
hardware load correctly, and does it work all right with other apps ?

Best,

dp



Istvan Varga wrote:

> Steven Yi wrote:
>
>> I recently updated to Fedora Core 4 and with that upgraded my ALSA
>> libs to 1.0.9 (was previously using 1.0.6).  It seems that now I am
>> unable to use -+rtaudio=alsa as Csound will fail with:
>>
>>  *** Failed while trying to set soundcard DMA buffer size
>> Failed to initialise real time audio output
>>
>> I have -b64 -B256 set, using --expression-opt and -m0 -d normally.  My
>> settings all worked before switching to FC4 and the new alsa libs. 
>> The Portaudio plugin seems to work alright, but would rather prefer to
>> use the ALSA plugin. I've tried various combinations of -b and -B as
>> well, without much luck.
>
>
> I only have ALSA 1.0.6 at this time, so some system upgrade is needed
> to have an attempt at fixing this problem, unless there was an obvious
> incompatible change in the ALSA API that broke the code below:
>
>     /* buffer size, */
>     if (dev->buffer_smps == 0) dev->buffer_smps = 1024;
>     if (dev->buffer_smps < 64) dev->buffer_smps = 64;
>     if (snd_pcm_hw_params_set_buffer_size(dev->handle, hw_params,
>                                           (snd_pcm_uframes_t) 
> dev->buffer_smps)
>         < 0) {
>       sprintf(msg, " *** Failed while trying to set soundcard "
>                    "DMA buffer size\n");
>       goto err_return_msg;
>     }
>
> By the way, did you try using different device names ? Does the error
> occur with all devices, and using any sample rate and number of 
> channels ?
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven:

  My apologies for not getting back to you sooner.

  I doubt that dmix is at fault here.

  I resolved my problems with ALSA by recompiling and reinstalling it. 
Demudi came with 1.0.9rc2, I upgraded to 1.0.9b and my difficulties were 
resolved. Btw, the major problem was a failure to install the virmidi 
module. The module was there but the loader said it wasn't. I still do 
not know exactly where the problem started, whether in the kernel, in 
ALSA, or in some system aspect of Demudi. Sorry I'm not much more help. :(

Best,

dp



Steven Yi wrote:

>Well, not much progress last night.  I read this today:
>
>http://www.reactivated.net/weblog/archives/2005/06/linux-2612/
>
>And seems that DMIX is enabled by default.  Could this possibly cause
>problems setting buffer sizes?  (I'm not using an .asoundrc file, btw)
>
>Anyways, will continue to search for info.  What does everyone think
>of if instead of failing if the buffer_size is not settable, to just
>log an error to the output to notify the user but to continue working?
> (I'm assuming if setting fails it just defaults to a deafult buffer
>size).
>
>steven
>
>
>On 8/29/05, Steven Yi  wrote:
>  
>
>>Hi Dave,
>>
>>This is precisely the combination I have.  I'm using Fedora Core 4
>>with Planet-CCRMA.  If I use ALSA 1.0.9 from CCRMA or atrpms, I end up
>>having problems altogether, but I think I'm using the ALSA rpm's from
>>newrpms (have to check when I get home).  As it is now, I can use
>>Amaraok and XMMS, play files from the commandline using play, and use
>>the portaudio plugin with Csound.  (Now that I think of it though, I'm
>>not sure if I've recompiled PortAudio v19 from source since moving
>>over to FC4, so wonder if that is what is allowing that to continue to
>>work...?).
>>
>>I'll experiment tonight to see if I can figure out anything.  What
>>problems did you have with 1.0.9 and 2.6.12, and what did you end up
>>doing to resolve it?
>>
>>steven
>>
>>
>>On 8/29/05, Dave Phillips  wrote:
>>    
>>
>>>Greetings:
>>>
>>>  I must note that I had a world of problems with ALSA 1.0.9 + kernel
>>>2.6.12. Steven, are you using a package-based distro ? Does your sound
>>>hardware load correctly, and does it work all right with other apps ?
>>>
>>>Best,
>>>
>>>dp
>>>
>>>
>>>
>>>Istvan Varga wrote:
>>>
>>>      
>>>
>>>>Steven Yi wrote:
>>>>
>>>>        
>>>>
>>>>>I recently updated to Fedora Core 4 and with that upgraded my ALSA
>>>>>libs to 1.0.9 (was previously using 1.0.6).  It seems that now I am
>>>>>unable to use -+rtaudio=alsa as Csound will fail with:
>>>>>
>>>>> *** Failed while trying to set soundcard DMA buffer size
>>>>>Failed to initialise real time audio output
>>>>>
>>>>>I have -b64 -B256 set, using --expression-opt and -m0 -d normally.  My
>>>>>settings all worked before switching to FC4 and the new alsa libs.
>>>>>The Portaudio plugin seems to work alright, but would rather prefer to
>>>>>use the ALSA plugin. I've tried various combinations of -b and -B as
>>>>>well, without much luck.
>>>>>          
>>>>>
>>>>I only have ALSA 1.0.6 at this time, so some system upgrade is needed
>>>>to have an attempt at fixing this problem, unless there was an obvious
>>>>incompatible change in the ALSA API that broke the code below:
>>>>
>>>>    /* buffer size, */
>>>>    if (dev->buffer_smps == 0) dev->buffer_smps = 1024;
>>>>    if (dev->buffer_smps < 64) dev->buffer_smps = 64;
>>>>    if (snd_pcm_hw_params_set_buffer_size(dev->handle, hw_params,
>>>>                                          (snd_pcm_uframes_t)
>>>>dev->buffer_smps)
>>>>        < 0) {
>>>>      sprintf(msg, " *** Failed while trying to set soundcard "
>>>>                   "DMA buffer size\n");
>>>>      goto err_return_msg;
>>>>    }
>>>>
>>>>By the way, did you try using different device names ? Does the error
>>>>occur with all devices, and using any sample rate and number of
>>>>channels ?
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>Practices
>>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>>>>& QA
>>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>>>_______________________________________________
>>>>Csound-devel mailing list
>>>>Csound-devel@lists.sourceforge.net
>>>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>        
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>Csound-devel mailing list
>>>Csound-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>      
>>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>  
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It is possible to find out the buffer sizes required by the dmix device,
by playing a WAV file with aplay using the -v -D dmix options. The value
printed for 'period_size' (I get 6000) should be used with -b, and
'buffer_size' (12000 for me) is the correct value for -B. Note that dmix
also limits the use of sample rates (I found that it only allows 48000 Hz).
However, it is definitely recommended to use the hw:* devices instead of
dmix, as the above buffer sizes (0.125 and 0.25 second) do not suggest
particularly good latency.

Steven Yi wrote:

> Hi Dave and all,
> 
> I tried changing alsa RPMs here and while some things somehow started
> working (like alsasequencer), still the same problem with csound. 
> However, I tried using "-+rtaudio=alsa -o dac:hw:0,0" and that worked!
>  If I explicitly use "-o dac:dmix" then I get the same error as if I
> use "-o dac".  So my current guess is that dmix *is* causing the
> problem with the rtalsa plugin.  Has anyone gotten csound to output to
> dmix using -+rtaudio=alsa ?


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote:

> Thanks for this info.  I will try this at home later tonight.  I am
> wondering though if there shouldn't be some kind of automatic
> detection of dmix (if possible) when using -o dac, as since it is now
> the default for kernel 2.6.12, I think this bug may affect others in
> the future. Perhaps a warning of some sort, or ignoring of user given
> buffer size params?  Or maybe this just needs to be documented?

I already made some changes for more helpful error messages, although
the new code is not committed yet. If setting the buffer size fails,
the nearest allowed size is printed, but it does not automatically
replace the value specified by the user.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Its definitely affected me Steven, and I'm following your progress.  Thanks,
Ken

Steven Yi wrote:

>Hi Istvan,
>
>Thanks for this info.  I will try this at home later tonight.  I am
>wondering though if there shouldn't be some kind of automatic
>detection of dmix (if possible) when using -o dac, as since it is now
>the default for kernel 2.6.12, I think this bug may affect others in
>the future. Perhaps a warning of some sort, or ignoring of user given
>buffer size params?  Or maybe this just needs to be documented?
>
>steven
>
>
>On 8/31/05, Istvan Varga  wrote:
>  
>
>>It is possible to find out the buffer sizes required by the dmix device,
>>by playing a WAV file with aplay using the -v -D dmix options. The value
>>printed for 'period_size' (I get 6000) should be used with -b, and
>>'buffer_size' (12000 for me) is the correct value for -B. Note that dmix
>>also limits the use of sample rates (I found that it only allows 48000 Hz).
>>However, it is definitely recommended to use the hw:* devices instead of
>>dmix, as the above buffer sizes (0.125 and 0.25 second) do not suggest
>>particularly good latency.
>>
>>Steven Yi wrote:
>>
>>    
>>
>>>Hi Dave and all,
>>>
>>>I tried changing alsa RPMs here and while some things somehow started
>>>working (like alsasequencer), still the same problem with csound.
>>>However, I tried using "-+rtaudio=alsa -o dac:hw:0,0" and that worked!
>>> If I explicitly use "-o dac:dmix" then I get the same error as if I
>>>use "-o dac".  So my current guess is that dmix *is* causing the
>>>problem with the rtalsa plugin.  Has anyone gotten csound to output to
>>>dmix using -+rtaudio=alsa ?
>>>      
>>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>  
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net