Hi all,

I am somewhat confused about the "sr" variable, on OSX at least.

Audio Output being configured to sr=48000, csound sr=44100

portaudio(cb): OK
jack: will complain about mismatch and abort
coreaudio: system will change to csound's sr

Internally csound will report always its own sample rate, even when using portaudio and the system is configured to another samplerate.

My question is: is there a way to know the system's samplerate from within csound? Or to leave it unspecified and use the system's samplerate? (leaving sr unspecified seems to be the same as setting it to 44100)

Here is the csd used to test:




.

sr = 44100
ksmps = 64
nchnls = 2
0dbfs = 1.0

instr 1
    kprevious init 0
    know timeinsts
    kdt = know - kprevious
    kprevious = know
    ksr = ksmps / kdt
    printk 0.5, ksr
endin

instr 2
    asin oscili 1.0, 440
    outch 1, asin
endin



i1 0 3600
i2 0 3600

Hi,

I think samplerate is so fundamental thing in csound that you cannot change it 
on the fly within orchestra. But you can do it before compiling it. For 
example if you use jack, jack_samplerate will return the samplerate of the 
server.

You could use a python script (or any other language that you prefer):
----------
import csnd6, command

samplerate = int(commands.getoutput("jack_samplerate"))

header = """
sr= %d
ksmps=32
nchnls=2
0dbfs=1
"""  %  samplerate

orc ="; the rest of your orchestra"
sco = "; your score if any"

c = csnd6.Csound()
c.SetOption("-odac:system:playback_")
c.SetOption("-+rtaudio=jack") 
c.CompileOrc(header+orc)     # Compile the Csound Orchestra string
c.ReadScore(sco)      # Compile the Csound SCO String
c.Start()  # When compiling from strings, this call is necessary before doing 
#any performing
c.Perform()  # Run Csound to completion
c.Stop()

-----------

I don't know but there must be ways to find out the samplerate of pulseaduio 
or coreaduio as well.

hope it helps!
tarmo

On Tuesday 04 March 2014 09:14:46 Eduardo Moguillansky wrote:
> Hi all,
> 
> I am somewhat confused about the "sr" variable, on OSX at least.
> 
> Audio Output being configured to sr=48000, csound sr=44100
> 
> portaudio(cb): OK
> jack: will complain about mismatch and abort
> coreaudio: system will change to csound's sr
> 
> Internally csound will report always its own sample rate, even when using
> portaudio and the system is configured to another samplerate.
> 
> My question is: is there a way to know the system's samplerate from within
> csound? Or to leave it unspecified and use the system's samplerate?
> (leaving sr unspecified seems to be the same as setting it to 44100)
> 
> Here is the csd used to test:
> 
> 
> 
> 
> .
> 
> sr = 44100
> ksmps = 64
> nchnls = 2
> 0dbfs = 1.0
> 
> instr 1
>     kprevious init 0
>     know timeinsts
>     kdt = know - kprevious
>     kprevious = know
>     ksr = ksmps / kdt
>     printk 0.5, ksr
> endin
> 
> instr 2
>     asin oscili 1.0, 440
>     outch 1, asin
> endin
> 
> 
> 
> i1 0 3600
> i2 0 3600
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>             https://sourceforge.net/p/csound/tickets/
> csound5:
>             https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

yes, that is IO-module dependent, because each IO module handles it differently (according to what they can do):

portaudio: portaudio includes a resampling facility, so it does it for you and you can just forget all about it
(however there is a cost in this).
jack: jack does not perform resampling, so it needs all of its applications to run with the same SR.
coreaudio: the coreaudio code just uses the OSX facility of setting the sampling rate so it doesn’t need to 
perform resampling. However, I think the downside is that lower SRs are not allowed.

Yes, you’re right that if you leave it unspecified it will be down to the default SR. We could investigate a
way to let it be set by the system SR, but I am not sure if it is possible, because by the time we start the
IO modules, Csound has already started with a given SR. It might be possible to enquire the system when
the module is loaded, before the first compilation and then, say if the SR is set to -1, to use this value.
Maybe you can open a feature request for us to investigate it.

Regards

Victor


On 4 Mar 2014, at 08:14, Eduardo Moguillansky  wrote:

> Hi all,
> 
> I am somewhat confused about the "sr" variable, on OSX at least.
> 
> Audio Output being configured to sr=48000, csound sr=44100
> 
> portaudio(cb): OK
> jack: will complain about mismatch and abort
> coreaudio: system will change to csound's sr
> 
> Internally csound will report always its own sample rate, even when using portaudio and the system is configured to another samplerate.
> 
> My question is: is there a way to know the system's samplerate from within csound? Or to leave it unspecified and use the system's samplerate? (leaving sr unspecified seems to be the same as setting it to 44100)
> 
> Here is the csd used to test:
> 
> 
> 
> 
> .
> 
> sr = 44100
> ksmps = 64
> nchnls = 2
> 0dbfs = 1.0
> 
> instr 1
>    kprevious init 0
>    know timeinsts
>    kdt = know - kprevious
>    kprevious = know
>    ksr = ksmps / kdt
>    printk 0.5, ksr
> endin
> 
> instr 2
>    asin oscili 1.0, 440
>    outch 1, asin
> endin
> 
> 
> 
> i1 0 3600
> i2 0 3600
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

For me the most important thing would be to unify the behavior of all platforms and backends. This would mean:

* include a flag to deny/allow resampling, so that csound complains if the internal sr is different to the system's sr. 
* SR = -1 is a great idea

The most problematic behavior until now is actually portaudio, because it seems to work most of the time, but when there is a sr mismatch, it will randomly output no sound and from csound's console output there is no indication of a sr mismatch. On the other hand, from my experience it seems to be the more stable backend in OSX (when jack is not involved)

For my use cases it would be extremely helpful if csound (the program, not the language) included things like:

$ csound --getsystemsamplerate
48000

$ csound --getoutdevices
0: dac0 (Built-in Output)
1: dac1 …
2: dac2 …

(This is the same as "csound -odac999 any.csd")

These could be easily parsed in any script and included in the command line used to launch csound (--sample-rate=N)

There are probably other tools that could be used to achieve this (as Tarmo suggested), but dependencies and installation uses prohibit such an approach, and given that csound already knows this information, it would be great to make it available. 

NB: I am ashamed to admit that I have no idea how to open a feature request.

On 04.03.2014, at 10:49, Victor Lazzarini  wrote:

> yes, that is IO-module dependent, because each IO module handles it differently (according to what they can do):
> 
> portaudio: portaudio includes a resampling facility, so it does it for you and you can just forget all about it
> (however there is a cost in this).
> jack: jack does not perform resampling, so it needs all of its applications to run with the same SR.
> coreaudio: the coreaudio code just uses the OSX facility of setting the sampling rate so it doesn’t need to 
> perform resampling. However, I think the downside is that lower SRs are not allowed.
> 
> Yes, you’re right that if you leave it unspecified it will be down to the default SR. We could investigate a
> way to let it be set by the system SR, but I am not sure if it is possible, because by the time we start the
> IO modules, Csound has already started with a given SR. It might be possible to enquire the system when
> the module is loaded, before the first compilation and then, say if the SR is set to -1, to use this value.
> Maybe you can open a feature request for us to investigate it.
> 
> Regards
> 
> Victor
> 
> 
> On 4 Mar 2014, at 08:14, Eduardo Moguillansky  wrote:
> 
>> Hi all,
>> 
>> I am somewhat confused about the "sr" variable, on OSX at least.
>> 
>> Audio Output being configured to sr=48000, csound sr=44100
>> 
>> portaudio(cb): OK
>> jack: will complain about mismatch and abort
>> coreaudio: system will change to csound's sr
>> 
>> Internally csound will report always its own sample rate, even when using portaudio and the system is configured to another samplerate.
>> 
>> My question is: is there a way to know the system's samplerate from within csound? Or to leave it unspecified and use the system's samplerate? (leaving sr unspecified seems to be the same as setting it to 44100)
>> 
>> Here is the csd used to test:
>> 
>> 
>> 
>> 
>> .
>> 
>> sr = 44100
>> ksmps = 64
>> nchnls = 2
>> 0dbfs = 1.0
>> 
>> instr 1
>>   kprevious init 0
>>   know timeinsts
>>   kdt = know - kprevious
>>   kprevious = know
>>   ksr = ksmps / kdt
>>   printk 0.5, ksr
>> endin
>> 
>> instr 2
>>   asin oscili 1.0, 440
>>   outch 1, asin
>> endin
>> 
>> 
>> 
>> i1 0 3600
>> i2 0 3600
>> 
>> 
>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug trackers
>> csound6:
>>           https://sourceforge.net/p/csound/tickets/
>> csound5:
>>           https://sourceforge.net/p/csound/bugs/
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

We actually have a means of listing in/outputs in the API, it is just not exposed in the command-line frontend, but it could be. The sampling rate can
also be added. However, as John said, maybe something like this could be a -U utility. 

To add a feature request, you need to register with sourceforge (if you have not already), log in and go to this page

https://sourceforge.net/p/csound/feature-requests/

click on create ticket and then add all the information you have.

Victor

On 4 Mar 2014, at 10:25, Eduardo Moguillansky  wrote:

> For me the most important thing would be to unify the behavior of all platforms and backends. This would mean:
> 
> * include a flag to deny/allow resampling, so that csound complains if the internal sr is different to the system's sr. 
> * SR = -1 is a great idea
> 
> The most problematic behavior until now is actually portaudio, because it seems to work most of the time, but when there is a sr mismatch, it will randomly output no sound and from csound's console output there is no indication of a sr mismatch. On the other hand, from my experience it seems to be the more stable backend in OSX (when jack is not involved)
> 
> For my use cases it would be extremely helpful if csound (the program, not the language) included things like:
> 
> $ csound --getsystemsamplerate
> 48000
> 
> $ csound --getoutdevices
> 0: dac0 (Built-in Output)
> 1: dac1 …
> 2: dac2 …
> 
> (This is the same as "csound -odac999 any.csd")
> 
> These could be easily parsed in any script and included in the command line used to launch csound (--sample-rate=N)
> 
> There are probably other tools that could be used to achieve this (as Tarmo suggested), but dependencies and installation uses prohibit such an approach, and given that csound already knows this information, it would be great to make it available. 
> 
> NB: I am ashamed to admit that I have no idea how to open a feature request.
> 
> On 04.03.2014, at 10:49, Victor Lazzarini  wrote:
> 
>> yes, that is IO-module dependent, because each IO module handles it differently (according to what they can do):
>> 
>> portaudio: portaudio includes a resampling facility, so it does it for you and you can just forget all about it
>> (however there is a cost in this).
>> jack: jack does not perform resampling, so it needs all of its applications to run with the same SR.
>> coreaudio: the coreaudio code just uses the OSX facility of setting the sampling rate so it doesn’t need to 
>> perform resampling. However, I think the downside is that lower SRs are not allowed.
>> 
>> Yes, you’re right that if you leave it unspecified it will be down to the default SR. We could investigate a
>> way to let it be set by the system SR, but I am not sure if it is possible, because by the time we start the
>> IO modules, Csound has already started with a given SR. It might be possible to enquire the system when
>> the module is loaded, before the first compilation and then, say if the SR is set to -1, to use this value.
>> Maybe you can open a feature request for us to investigate it.
>> 
>> Regards
>> 
>> Victor
>> 
>> 
>> On 4 Mar 2014, at 08:14, Eduardo Moguillansky  wrote:
>> 
>>> Hi all,
>>> 
>>> I am somewhat confused about the "sr" variable, on OSX at least.
>>> 
>>> Audio Output being configured to sr=48000, csound sr=44100
>>> 
>>> portaudio(cb): OK
>>> jack: will complain about mismatch and abort
>>> coreaudio: system will change to csound's sr
>>> 
>>> Internally csound will report always its own sample rate, even when using portaudio and the system is configured to another samplerate.
>>> 
>>> My question is: is there a way to know the system's samplerate from within csound? Or to leave it unspecified and use the system's samplerate? (leaving sr unspecified seems to be the same as setting it to 44100)
>>> 
>>> Here is the csd used to test:
>>> 
>>> 
>>> 
>>> 
>>> .
>>> 
>>> sr = 44100
>>> ksmps = 64
>>> nchnls = 2
>>> 0dbfs = 1.0
>>> 
>>> instr 1
>>>  kprevious init 0
>>>  know timeinsts
>>>  kdt = know - kprevious
>>>  kprevious = know
>>>  ksr = ksmps / kdt
>>>  printk 0.5, ksr
>>> endin
>>> 
>>> instr 2
>>>  asin oscili 1.0, 440
>>>  outch 1, asin
>>> endin
>>> 
>>> 
>>> 
>>> i1 0 3600
>>> i2 0 3600
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug trackers
>>> csound6:
>>>          https://sourceforge.net/p/csound/tickets/
>>> csound5:
>>>          https://sourceforge.net/p/csound/bugs/
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>> 
>>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug trackers
>> csound6:
>>           https://sourceforge.net/p/csound/tickets/
>> csound5:
>>           https://sourceforge.net/p/csound/bugs/
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

that’s a great idea.
On 4 Mar 2014, at 10:45, jpff@cs.bath.ac.uk wrote:

> Would it be a good idea to extend the monthly administration message to incluse information on creating tickets?
> 
> ==John ff
> 
> 
> Quoting Victor Lazzarini :
> 
>> To add a feature request, you need to register with sourceforge (if you have not already), log in and go to this page
>> 
>> https://sourceforge.net/p/csound/feature-requests/
>> 
>> click on create ticket and then add all the information you have.
>> 
>> Victor
>> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>           https://sourceforge.net/p/csound/tickets/
> csound5:
>           https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Ok 1/2 of this request is done, now there is a —devices[=in|out] long option that allows device listing from the csound command.
That was easy enough, since the API already supported this.

The second part (system sample rate report) will take more thinking (not because it’s hard, but because we want to find the
best way of doing this).

Victor

On 4 Mar 2014, at 10:25, Eduardo Moguillansky  wrote:

> For me the most important thing would be to unify the behavior of all platforms and backends. This would mean:
> 
> * include a flag to deny/allow resampling, so that csound complains if the internal sr is different to the system's sr. 
> * SR = -1 is a great idea
> 
> The most problematic behavior until now is actually portaudio, because it seems to work most of the time, but when there is a sr mismatch, it will randomly output no sound and from csound's console output there is no indication of a sr mismatch. On the other hand, from my experience it seems to be the more stable backend in OSX (when jack is not involved)
> 
> For my use cases it would be extremely helpful if csound (the program, not the language) included things like:
> 
> $ csound --getsystemsamplerate
> 48000
> 
> $ csound --getoutdevices
> 0: dac0 (Built-in Output)
> 1: dac1 …
> 2: dac2 …
> 
> (This is the same as "csound -odac999 any.csd")
> 
> These could be easily parsed in any script and included in the command line used to launch csound (--sample-rate=N)
> 
> There are probably other tools that could be used to achieve this (as Tarmo suggested), but dependencies and installation uses prohibit such an approach, and given that csound already knows this information, it would be great to make it available. 
> 
> NB: I am ashamed to admit that I have no idea how to open a feature request.
> 
> On 04.03.2014, at 10:49, Victor Lazzarini  wrote:
> 
>> yes, that is IO-module dependent, because each IO module handles it differently (according to what they can do):
>> 
>> portaudio: portaudio includes a resampling facility, so it does it for you and you can just forget all about it
>> (however there is a cost in this).
>> jack: jack does not perform resampling, so it needs all of its applications to run with the same SR.
>> coreaudio: the coreaudio code just uses the OSX facility of setting the sampling rate so it doesn’t need to 
>> perform resampling. However, I think the downside is that lower SRs are not allowed.
>> 
>> Yes, you’re right that if you leave it unspecified it will be down to the default SR. We could investigate a
>> way to let it be set by the system SR, but I am not sure if it is possible, because by the time we start the
>> IO modules, Csound has already started with a given SR. It might be possible to enquire the system when
>> the module is loaded, before the first compilation and then, say if the SR is set to -1, to use this value.
>> Maybe you can open a feature request for us to investigate it.
>> 
>> Regards
>> 
>> Victor
>> 
>> 
>> On 4 Mar 2014, at 08:14, Eduardo Moguillansky  wrote:
>> 
>>> Hi all,
>>> 
>>> I am somewhat confused about the "sr" variable, on OSX at least.
>>> 
>>> Audio Output being configured to sr=48000, csound sr=44100
>>> 
>>> portaudio(cb): OK
>>> jack: will complain about mismatch and abort
>>> coreaudio: system will change to csound's sr
>>> 
>>> Internally csound will report always its own sample rate, even when using portaudio and the system is configured to another samplerate.
>>> 
>>> My question is: is there a way to know the system's samplerate from within csound? Or to leave it unspecified and use the system's samplerate? (leaving sr unspecified seems to be the same as setting it to 44100)
>>> 
>>> Here is the csd used to test:
>>> 
>>> 
>>> 
>>> 
>>> .
>>> 
>>> sr = 44100
>>> ksmps = 64
>>> nchnls = 2
>>> 0dbfs = 1.0
>>> 
>>> instr 1
>>>  kprevious init 0
>>>  know timeinsts
>>>  kdt = know - kprevious
>>>  kprevious = know
>>>  ksr = ksmps / kdt
>>>  printk 0.5, ksr
>>> endin
>>> 
>>> instr 2
>>>  asin oscili 1.0, 440
>>>  outch 1, asin
>>> endin
>>> 
>>> 
>>> 
>>> i1 0 3600
>>> i2 0 3600
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug trackers
>>> csound6:
>>>          https://sourceforge.net/p/csound/tickets/
>>> csound5:
>>>          https://sourceforge.net/p/csound/bugs/
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>> 
>>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug trackers
>> csound6:
>>           https://sourceforge.net/p/csound/tickets/
>> csound5:
>>           https://sourceforge.net/p/csound/bugs/
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

yes, and could you (john) include how to send a bug report?
thanks and best regards -
	joachim


Am 04.03.2014 12:01, schrieb Victor Lazzarini:
> that’s a great idea.
> On 4 Mar 2014, at 10:45, jpff@cs.bath.ac.uk wrote:
>
>> Would it be a good idea to extend the monthly administration message to incluse information on creating tickets?
>>
>> ==John ff
>>
>>
>> Quoting Victor Lazzarini :
>>
>>> To add a feature request, you need to register with sourceforge (if you have not already), log in and go to this page
>>>
>>> https://sourceforge.net/p/csound/feature-requests/
>>>
>>> click on create ticket and then add all the information you have.
>>>
>>> Victor
>>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug trackers
>> csound6:
>>            https://sourceforge.net/p/csound/tickets/
>> csound5:
>>            https://sourceforge.net/p/csound/bugs/
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>              https://sourceforge.net/p/csound/tickets/
> csound5:
>              https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>