PulseAudio support for Nyquist

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PulseAudio support for Nyquist

Stevethefiddle
Cc: to Roger Dannenberg

Currently, Nyquist plug-ins can play sound directly on Windows, which
Robert has demonstrated is a very useful accessibility feature.
Unfortunately this does not work reliably on Linux as Nyquist does not
support PulseAudio (ALSA only).

If PulseAudio was supported, then in effect, Jack would also be
supported (via module-jack-sink), so Nyquist would have pretty awesome
playback support on Linux.

I think this is a "Nyquist issue" rather than an "Audacity issue",
though the main beneficiary would be Audacity. Where should this
feature request be logged?

Also, what's the chance of this happening in the foreseeable future?

Steve

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Stevethefiddle
On 15 June 2017 at 19:23, Roger Dannenberg <[hidden email]> wrote:
> Interesting. Nyquist uses PortAudio, so it should work with whatever
> devices and API's work in Audacity.

Oh! That's a surprise. It appears to work only with ALSA, and all I
could find in the documentation was that it should work with ALSA (no
mention of Pulse or Jack).

> PortAudio is easiest to configure
> via a graphical interface where you can see and select devices. This
> doesn't work so well for a text-based programming language, but Nyquist
> has a way of avoiding PortAudio's default device. Here's what Nyquist
> (from a command line) prints the first time you call play:
>
> SAL> play osc(c4)
>
> Saving sound file to /tmp/rbd-temp.wav
> PortAudio 0: Built-in Microph -- Core Audio
> PortAudio 1: Built-in Output -- Core Audio
> PortAudio 2: Aggregate Device -- Core Audio
> ... Default device is 1
> ... Selected device 1 for output
>
> total samples: 44100 (1 seconds)

From the Nyquist prompt, all I see from:

;codetype sal
play osc(c4)
return "Done

is:

Saving sound file to /tmp/steve-temp.wav
 44880
total samples: 88200
AutoNorm: peak was 1,
     peak after normalization was 0.9,
     suggested manual normalization factor is 0.9


>
> Set *snd-list-devices* = t
>   and call play to see device list again.
> Set *snd-device* to a fixnum to select an output device
>   or set *snd-device* to a substring of a device name
>   to select the first device containing the substring.

In the Nyquist Prompt, the debug output from,

;codetpe sal
set *snd-list-devices* = t
play osc(c4)
return "Done"

is


>>> parse warning: Identifier contains operator character(s).
        Perhaps you omitted spaces around an operator.
>>> in NIL, line 2, col 5.

set *snd-list-devices* = t
    ^
Saving sound file to /tmp/steve-temp.wav
 44880
total samples: 69120
AutoNorm: peak was 1,
     peak after normalization was 0.9,
     suggested manual normalization factor is 0.9


There's no mention of PortAudio or devices.

If Audacity is set to use Pulse, and there has been playback from
Audacity, then Nyquist reports:

Saving sound file to /tmp/steve-temp.wav
warning: could not open audio, error -9985, Device unavailable.

Similarly, if any other application has access to the the audio
device, Nyquist refuses to play and warns that the device is
unavailable.

If PulseAudio volume control is open - same thing - Device unavailable.

On the other hand, if Audacity is set to use the "hw" ALSA device, and
no other applications are accessing the sound card, then Nyquist plays
fine (though Nyquist latency settings do not work correctly -
http://bugzilla.audacityteam.org/show_bug.cgi?id=570)

This strongly suggests that Nyquist only has access to ALSA and not PulseAudio.

>
> I'm not sure how Audacity and Nyquist are compiled on Linux. It's
> possible that Nyquist is linked with it's own private configuration of
> PortAudio although I'd expect that to cause some linker conflicts. Maybe
> the problem is just that Nyquist, without further instructions, is
> opening PortAudio's default device which might always be ALSA, giving
> the impression that it does not support other APIs. What do you think?

I don't really know where to start looking, but I did notice a comment in
lib-src/libnyquist/nyquist/sys/unix/alsa/system.lsp

;; WARNING: if you invoke an external program to play files,
;; but Nyquist uses internal (portaudio) interface to
;; play synthesized sound, Nyquist may fail to open the
;; sound device while it is playing a sound file and then
;; refuse to play anything. -RBD dec05

It would certainly be very useful if Nyquist could be coaxed into
working with Pulse. That you say it should work, is encouraging.

Steve

>
> -Roger
>
>
> On 6/15/17 12:28 PM, Steve the Fiddle wrote:
>> Cc: to Roger Dannenberg
>>
>> Currently, Nyquist plug-ins can play sound directly on Windows, which
>> Robert has demonstrated is a very useful accessibility feature.
>> Unfortunately this does not work reliably on Linux as Nyquist does not
>> support PulseAudio (ALSA only).
>>
>> If PulseAudio was supported, then in effect, Jack would also be
>> supported (via module-jack-sink), so Nyquist would have pretty awesome
>> playback support on Linux.
>>
>> I think this is a "Nyquist issue" rather than an "Audacity issue",
>> though the main beneficiary would be Audacity. Where should this
>> feature request be logged?
>>
>> Also, what's the chance of this happening in the foreseeable future?
>>
>> Steve
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Stevethefiddle
On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:

> I would expect Nyquist to be most modified for Audacity in the area of
> audio output since Audacity should "own" audio output. It seems like a
> bug (or unanticipated "feature") that Nyquist can do output at all.
>
> All the stuff I described for queries and specifying the preferred audio
> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
> the code used for building Nyquist in Audacity.  Specifically look for
>
>         if (list) {
>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>                            device_info->name, host_info->name);
>         }


That's interesting - those lines do not exist, but what there is in
sndwritepa.c is:

// Initialize the audio stream for output
// If this is Linux, prefer to open ALSA device
num_devices = Pa_GetDeviceCount();
for (i = 0; i < num_devices; i++) {
   device_info = Pa_GetDeviceInfo(i);
   host_info = Pa_GetHostApiInfo(device_info->hostApi);
   if (host_info->type == paALSA) {
      output_parameters.device = i;
      break;
   }
}


and if I remove the special case for Linux:

num_devices = Pa_GetDeviceCount();
for (i = 0; i < num_devices; i++) {
   device_info = Pa_GetDeviceInfo(i);
   host_info = Pa_GetHostApiInfo(device_info->hostApi);
   // if (host_info->type == paALSA) {
   //    output_parameters.device = i;
   //    break;
   //}
}

Then Nyquist does indeed use Pulse.

Ah, just a moment - looking in the source for standalone Nyquist I see:

// giving preference to first ALSA device seems to be a bad idea
// if (j == -1 && host_info->type == paALSA) {
//     j = i;
// }

So it looks like you fixed this problem in Nyquist some time ago, but
in Audacity this code has not been touched in at least 8 years.

So, updating LVAL prepare_audio(...)
https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7

I'm even less familiar with C than I am with C++, so would you be able
to cast your expert eye over this Roger?

Steve

>
> which is in sndwritepa.c and where devices get listed to the Nyquist
> console output.
>
> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>> ;; WARNING: if you invoke an external program to play files,
>> ;; but Nyquist uses internal (portaudio) interface to
>> ;; play synthesized sound, Nyquist may fail to open the
>> ;; sound device while it is playing a sound file and then
>> ;; refuse to play anything. -RBD dec05
> I think what this means is that if you try to play through PortAudio
> with Nyquist and Nyquist fails to open the audio device because it is
> locked by something else, Nyquist might have problems. I'm not sure what
> this is about, but I can imagine Nyquist getting into some weird state
> if it's all set to play audio and then encounters errors -- it's not a
> normal situation, but I should check this out and improve error recovery.
>
> -Roger
>
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Robert Hänggi
Bravo Steve
It seems that you're finally making some headway.

Robert

On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:

> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>> I would expect Nyquist to be most modified for Audacity in the area of
>> audio output since Audacity should "own" audio output. It seems like a
>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>
>> All the stuff I described for queries and specifying the preferred audio
>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
>> the code used for building Nyquist in Audacity.  Specifically look for
>>
>>         if (list) {
>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>                            device_info->name, host_info->name);
>>         }
>
>
> That's interesting - those lines do not exist, but what there is in
> sndwritepa.c is:
>
> // Initialize the audio stream for output
> // If this is Linux, prefer to open ALSA device
> num_devices = Pa_GetDeviceCount();
> for (i = 0; i < num_devices; i++) {
>    device_info = Pa_GetDeviceInfo(i);
>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>    if (host_info->type == paALSA) {
>       output_parameters.device = i;
>       break;
>    }
> }
>
>
> and if I remove the special case for Linux:
>
> num_devices = Pa_GetDeviceCount();
> for (i = 0; i < num_devices; i++) {
>    device_info = Pa_GetDeviceInfo(i);
>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>    // if (host_info->type == paALSA) {
>    //    output_parameters.device = i;
>    //    break;
>    //}
> }
>
> Then Nyquist does indeed use Pulse.
>
> Ah, just a moment - looking in the source for standalone Nyquist I see:
>
> // giving preference to first ALSA device seems to be a bad idea
> // if (j == -1 && host_info->type == paALSA) {
> //     j = i;
> // }
>
> So it looks like you fixed this problem in Nyquist some time ago, but
> in Audacity this code has not been touched in at least 8 years.
>
> So, updating LVAL prepare_audio(...)
> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>
> I'm even less familiar with C than I am with C++, so would you be able
> to cast your expert eye over this Roger?
>
> Steve
>
>>
>> which is in sndwritepa.c and where devices get listed to the Nyquist
>> console output.
>>
>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>> ;; WARNING: if you invoke an external program to play files,
>>> ;; but Nyquist uses internal (portaudio) interface to
>>> ;; play synthesized sound, Nyquist may fail to open the
>>> ;; sound device while it is playing a sound file and then
>>> ;; refuse to play anything. -RBD dec05
>> I think what this means is that if you try to play through PortAudio
>> with Nyquist and Nyquist fails to open the audio device because it is
>> locked by something else, Nyquist might have problems. I'm not sure what
>> this is about, but I can imagine Nyquist getting into some weird state
>> if it's all set to play audio and then encounters errors -- it's not a
>> normal situation, but I should check this out and improve error recovery.
>>
>> -Roger
>>
>>
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Stevethefiddle
On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]> wrote:
> Bravo Steve
> It seems that you're finally making some headway.

Thanks Robert. It's working terrifically on my machine.

By default Nyquist uses PulseAudio, which is the system default
output, and the default for Audacity.

With the default, Nyquist can play, or in the case of your accessible
plug-in it can talk, even if other applications are playing. This is
good news as it probably means (not tested yet) that it will work
while Orca screen reader is active. It also solves the problem with
playing oddball sample rates because PulseAudio can resample to a
supported rate on the fly.

With the aid of *snd-list-devices* and *snd-device* it is also
possible to set Nyquist to play directly through Jack Audio System (if
Jack is running), and that is "proper" jack playback, not piped
through PulseAudio. I  don't think that we can make much practical use
of device selection in mainstream plug-ins, but it's terrific for
experimenting.

A possible refinement would be for Nyquist to prefer Jack if Jack is
running, but I'm not overly concerned about that as (1) Nyquist will
prefer Jack if Jack is the system default, (2) If Pulse is the system
default and the user is using Jack, they will probably ("should") have
module-jack-sink set up for non-jack applications.

I'm not sure what the policy / etiquette is for modifying libnyquist.
Normally we try to avoid modifying libraries, but libnyquist is a bit
of a special case as I think Audacity is the only application that
uses libnyquist, and the file in question is currently different from
the upstream (standalone) version. It's probably a matter for Roger to
decide.

Steve

>
> Robert
>
> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>> I would expect Nyquist to be most modified for Audacity in the area of
>>> audio output since Audacity should "own" audio output. It seems like a
>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>
>>> All the stuff I described for queries and specifying the preferred audio
>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
>>> the code used for building Nyquist in Audacity.  Specifically look for
>>>
>>>         if (list) {
>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>                            device_info->name, host_info->name);
>>>         }
>>
>>
>> That's interesting - those lines do not exist, but what there is in
>> sndwritepa.c is:
>>
>> // Initialize the audio stream for output
>> // If this is Linux, prefer to open ALSA device
>> num_devices = Pa_GetDeviceCount();
>> for (i = 0; i < num_devices; i++) {
>>    device_info = Pa_GetDeviceInfo(i);
>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>    if (host_info->type == paALSA) {
>>       output_parameters.device = i;
>>       break;
>>    }
>> }
>>
>>
>> and if I remove the special case for Linux:
>>
>> num_devices = Pa_GetDeviceCount();
>> for (i = 0; i < num_devices; i++) {
>>    device_info = Pa_GetDeviceInfo(i);
>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>    // if (host_info->type == paALSA) {
>>    //    output_parameters.device = i;
>>    //    break;
>>    //}
>> }
>>
>> Then Nyquist does indeed use Pulse.
>>
>> Ah, just a moment - looking in the source for standalone Nyquist I see:
>>
>> // giving preference to first ALSA device seems to be a bad idea
>> // if (j == -1 && host_info->type == paALSA) {
>> //     j = i;
>> // }
>>
>> So it looks like you fixed this problem in Nyquist some time ago, but
>> in Audacity this code has not been touched in at least 8 years.
>>
>> So, updating LVAL prepare_audio(...)
>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>
>> I'm even less familiar with C than I am with C++, so would you be able
>> to cast your expert eye over this Roger?
>>
>> Steve
>>
>>>
>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>> console output.
>>>
>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>> ;; WARNING: if you invoke an external program to play files,
>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>> ;; sound device while it is playing a sound file and then
>>>> ;; refuse to play anything. -RBD dec05
>>> I think what this means is that if you try to play through PortAudio
>>> with Nyquist and Nyquist fails to open the audio device because it is
>>> locked by something else, Nyquist might have problems. I'm not sure what
>>> this is about, but I can imagine Nyquist getting into some weird state
>>> if it's all set to play audio and then encounters errors -- it's not a
>>> normal situation, but I should check this out and improve error recovery.
>>>
>>> -Roger
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Robert Hänggi
On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:

> On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]> wrote:
>> Bravo Steve
>> It seems that you're finally making some headway.
>
> Thanks Robert. It's working terrifically on my machine.
>
> By default Nyquist uses PulseAudio, which is the system default
> output, and the default for Audacity.
>
> With the default, Nyquist can play, or in the case of your accessible
> plug-in it can talk, even if other applications are playing. This is
> good news as it probably means (not tested yet) that it will work
> while Orca screen reader is active. It also solves the problem with
> playing oddball sample rates because PulseAudio can resample to a
> supported rate on the fly.
>
> With the aid of *snd-list-devices* and *snd-device* it is also
> possible to set Nyquist to play directly through Jack Audio System (if
> Jack is running), and that is "proper" jack playback, not piped
> through PulseAudio. I  don't think that we can make much practical use
> of device selection in mainstream plug-ins, but it's terrific for
> experimenting.
>
> A possible refinement would be for Nyquist to prefer Jack if Jack is
> running, but I'm not overly concerned about that as (1) Nyquist will
> prefer Jack if Jack is the system default, (2) If Pulse is the system
> default and the user is using Jack, they will probably ("should") have
> module-jack-sink set up for non-jack applications.
>
> I'm not sure what the policy / etiquette is for modifying libnyquist.
> Normally we try to avoid modifying libraries, but libnyquist is a bit
> of a special case as I think Audacity is the only application that
> uses libnyquist, and the file in question is currently different from
> the upstream (standalone) version. It's probably a matter for Roger to
> decide.
>

It is certainly cool that the accessible plug-ins will work with Orca
(very likely) since the screen reader doesn't support custom scripts.

Is a comparable improvement achievable for the Mac?
I think it's the worst of the three platforms as it never played sound at all.

Apropos updating.
We've replaced "convolve.c" in the last upgrade with an old version
because it was under development. I think that it now should be fine
(upstream), ready to integrate.
There are possibly some other functions that are only half ways finished.
For instance 'snd-phasevocoder' is only a stub version in Audacity and
should as such be disabled until we move to Nyquist 3.10 or so.

Robert

> Steve
>
>>
>> Robert
>>
>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>>> I would expect Nyquist to be most modified for Audacity in the area of
>>>> audio output since Audacity should "own" audio output. It seems like a
>>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>>
>>>> All the stuff I described for queries and specifying the preferred audio
>>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
>>>> the code used for building Nyquist in Audacity.  Specifically look for
>>>>
>>>>         if (list) {
>>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>>                            device_info->name, host_info->name);
>>>>         }
>>>
>>>
>>> That's interesting - those lines do not exist, but what there is in
>>> sndwritepa.c is:
>>>
>>> // Initialize the audio stream for output
>>> // If this is Linux, prefer to open ALSA device
>>> num_devices = Pa_GetDeviceCount();
>>> for (i = 0; i < num_devices; i++) {
>>>    device_info = Pa_GetDeviceInfo(i);
>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>    if (host_info->type == paALSA) {
>>>       output_parameters.device = i;
>>>       break;
>>>    }
>>> }
>>>
>>>
>>> and if I remove the special case for Linux:
>>>
>>> num_devices = Pa_GetDeviceCount();
>>> for (i = 0; i < num_devices; i++) {
>>>    device_info = Pa_GetDeviceInfo(i);
>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>    // if (host_info->type == paALSA) {
>>>    //    output_parameters.device = i;
>>>    //    break;
>>>    //}
>>> }
>>>
>>> Then Nyquist does indeed use Pulse.
>>>
>>> Ah, just a moment - looking in the source for standalone Nyquist I see:
>>>
>>> // giving preference to first ALSA device seems to be a bad idea
>>> // if (j == -1 && host_info->type == paALSA) {
>>> //     j = i;
>>> // }
>>>
>>> So it looks like you fixed this problem in Nyquist some time ago, but
>>> in Audacity this code has not been touched in at least 8 years.
>>>
>>> So, updating LVAL prepare_audio(...)
>>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>>
>>> I'm even less familiar with C than I am with C++, so would you be able
>>> to cast your expert eye over this Roger?
>>>
>>> Steve
>>>
>>>>
>>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>>> console output.
>>>>
>>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>>> ;; WARNING: if you invoke an external program to play files,
>>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>>> ;; sound device while it is playing a sound file and then
>>>>> ;; refuse to play anything. -RBD dec05
>>>> I think what this means is that if you try to play through PortAudio
>>>> with Nyquist and Nyquist fails to open the audio device because it is
>>>> locked by something else, Nyquist might have problems. I'm not sure what
>>>> this is about, but I can imagine Nyquist getting into some weird state
>>>> if it's all set to play audio and then encounters errors -- it's not a
>>>> normal situation, but I should check this out and improve error
>>>> recovery.
>>>>
>>>> -Roger
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Stevethefiddle
On 17 June 2017 at 07:20, Robert Hänggi <[hidden email]> wrote:

> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]> wrote:
>>> Bravo Steve
>>> It seems that you're finally making some headway.
>>
>> Thanks Robert. It's working terrifically on my machine.
>>
>> By default Nyquist uses PulseAudio, which is the system default
>> output, and the default for Audacity.
>>
>> With the default, Nyquist can play, or in the case of your accessible
>> plug-in it can talk, even if other applications are playing. This is
>> good news as it probably means (not tested yet) that it will work
>> while Orca screen reader is active. It also solves the problem with
>> playing oddball sample rates because PulseAudio can resample to a
>> supported rate on the fly.
>>
>> With the aid of *snd-list-devices* and *snd-device* it is also
>> possible to set Nyquist to play directly through Jack Audio System (if
>> Jack is running), and that is "proper" jack playback, not piped
>> through PulseAudio. I  don't think that we can make much practical use
>> of device selection in mainstream plug-ins, but it's terrific for
>> experimenting.
>>
>> A possible refinement would be for Nyquist to prefer Jack if Jack is
>> running, but I'm not overly concerned about that as (1) Nyquist will
>> prefer Jack if Jack is the system default, (2) If Pulse is the system
>> default and the user is using Jack, they will probably ("should") have
>> module-jack-sink set up for non-jack applications.
>>
>> I'm not sure what the policy / etiquette is for modifying libnyquist.
>> Normally we try to avoid modifying libraries, but libnyquist is a bit
>> of a special case as I think Audacity is the only application that
>> uses libnyquist, and the file in question is currently different from
>> the upstream (standalone) version. It's probably a matter for Roger to
>> decide.
>>
>
> It is certainly cool that the accessible plug-ins will work with Orca
> (very likely) since the screen reader doesn't support custom scripts.
>
> Is a comparable improvement achievable for the Mac?
> I think it's the worst of the three platforms as it never played sound at all.

I've now tested on Mac, and I don't think that statement is completely
correct. Testing of Sierra, Nyquist playbacks does work, but there is
no indication of what output device is being used. If, as happened
during my testing, the default output device is turned off, then it
appears there is no playback. The proposed patch to sndwrite.pa is
very helpful for resolving this problem as you can set
*snd-list-devices* to 'true' and Nyquist will report which devices are
available and which is currently selected.

This is probably a good case for implementing Roger's suggestion of
making the default device for Nyquist the same as Audacity's selected
output. To do that, we would need to playback  from Nyquist through
ALSA, but it looks like we can do that by reducing the default
latency.

Steve

>
> Apropos updating.
> We've replaced "convolve.c" in the last upgrade with an old version
> because it was under development. I think that it now should be fine
> (upstream), ready to integrate.
> There are possibly some other functions that are only half ways finished.
> For instance 'snd-phasevocoder' is only a stub version in Audacity and
> should as such be disabled until we move to Nyquist 3.10 or so.
>
> Robert
>
>> Steve
>>
>>>
>>> Robert
>>>
>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>>>> I would expect Nyquist to be most modified for Audacity in the area of
>>>>> audio output since Audacity should "own" audio output. It seems like a
>>>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>>>
>>>>> All the stuff I described for queries and specifying the preferred audio
>>>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
>>>>> the code used for building Nyquist in Audacity.  Specifically look for
>>>>>
>>>>>         if (list) {
>>>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>>>                            device_info->name, host_info->name);
>>>>>         }
>>>>
>>>>
>>>> That's interesting - those lines do not exist, but what there is in
>>>> sndwritepa.c is:
>>>>
>>>> // Initialize the audio stream for output
>>>> // If this is Linux, prefer to open ALSA device
>>>> num_devices = Pa_GetDeviceCount();
>>>> for (i = 0; i < num_devices; i++) {
>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>    if (host_info->type == paALSA) {
>>>>       output_parameters.device = i;
>>>>       break;
>>>>    }
>>>> }
>>>>
>>>>
>>>> and if I remove the special case for Linux:
>>>>
>>>> num_devices = Pa_GetDeviceCount();
>>>> for (i = 0; i < num_devices; i++) {
>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>    // if (host_info->type == paALSA) {
>>>>    //    output_parameters.device = i;
>>>>    //    break;
>>>>    //}
>>>> }
>>>>
>>>> Then Nyquist does indeed use Pulse.
>>>>
>>>> Ah, just a moment - looking in the source for standalone Nyquist I see:
>>>>
>>>> // giving preference to first ALSA device seems to be a bad idea
>>>> // if (j == -1 && host_info->type == paALSA) {
>>>> //     j = i;
>>>> // }
>>>>
>>>> So it looks like you fixed this problem in Nyquist some time ago, but
>>>> in Audacity this code has not been touched in at least 8 years.
>>>>
>>>> So, updating LVAL prepare_audio(...)
>>>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>>>
>>>> I'm even less familiar with C than I am with C++, so would you be able
>>>> to cast your expert eye over this Roger?
>>>>
>>>> Steve
>>>>
>>>>>
>>>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>>>> console output.
>>>>>
>>>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>>>> ;; WARNING: if you invoke an external program to play files,
>>>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>>>> ;; sound device while it is playing a sound file and then
>>>>>> ;; refuse to play anything. -RBD dec05
>>>>> I think what this means is that if you try to play through PortAudio
>>>>> with Nyquist and Nyquist fails to open the audio device because it is
>>>>> locked by something else, Nyquist might have problems. I'm not sure what
>>>>> this is about, but I can imagine Nyquist getting into some weird state
>>>>> if it's all set to play audio and then encounters errors -- it's not a
>>>>> normal situation, but I should check this out and improve error
>>>>> recovery.
>>>>>
>>>>> -Roger
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Robert Hänggi
I don't understand the last point.

Does it mean that Nyquist assumes that it sends the output to Alsa but
in reality Audacity's default device--whatever it is--is used?

Robert

On 19/06/2017, Steve the Fiddle <[hidden email]> wrote:

> On 17 June 2017 at 07:20, Robert Hänggi <[hidden email]> wrote:
>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]> wrote:
>>>> Bravo Steve
>>>> It seems that you're finally making some headway.
>>>
>>> Thanks Robert. It's working terrifically on my machine.
>>>
>>> By default Nyquist uses PulseAudio, which is the system default
>>> output, and the default for Audacity.
>>>
>>> With the default, Nyquist can play, or in the case of your accessible
>>> plug-in it can talk, even if other applications are playing. This is
>>> good news as it probably means (not tested yet) that it will work
>>> while Orca screen reader is active. It also solves the problem with
>>> playing oddball sample rates because PulseAudio can resample to a
>>> supported rate on the fly.
>>>
>>> With the aid of *snd-list-devices* and *snd-device* it is also
>>> possible to set Nyquist to play directly through Jack Audio System (if
>>> Jack is running), and that is "proper" jack playback, not piped
>>> through PulseAudio. I  don't think that we can make much practical use
>>> of device selection in mainstream plug-ins, but it's terrific for
>>> experimenting.
>>>
>>> A possible refinement would be for Nyquist to prefer Jack if Jack is
>>> running, but I'm not overly concerned about that as (1) Nyquist will
>>> prefer Jack if Jack is the system default, (2) If Pulse is the system
>>> default and the user is using Jack, they will probably ("should") have
>>> module-jack-sink set up for non-jack applications.
>>>
>>> I'm not sure what the policy / etiquette is for modifying libnyquist.
>>> Normally we try to avoid modifying libraries, but libnyquist is a bit
>>> of a special case as I think Audacity is the only application that
>>> uses libnyquist, and the file in question is currently different from
>>> the upstream (standalone) version. It's probably a matter for Roger to
>>> decide.
>>>
>>
>> It is certainly cool that the accessible plug-ins will work with Orca
>> (very likely) since the screen reader doesn't support custom scripts.
>>
>> Is a comparable improvement achievable for the Mac?
>> I think it's the worst of the three platforms as it never played sound at
>> all.
>
> I've now tested on Mac, and I don't think that statement is completely
> correct. Testing of Sierra, Nyquist playbacks does work, but there is
> no indication of what output device is being used. If, as happened
> during my testing, the default output device is turned off, then it
> appears there is no playback. The proposed patch to sndwrite.pa is
> very helpful for resolving this problem as you can set
> *snd-list-devices* to 'true' and Nyquist will report which devices are
> available and which is currently selected.
>
> This is probably a good case for implementing Roger's suggestion of
> making the default device for Nyquist the same as Audacity's selected
> output. To do that, we would need to playback  from Nyquist through
> ALSA, but it looks like we can do that by reducing the default
> latency.
>
> Steve
>
>>
>> Apropos updating.
>> We've replaced "convolve.c" in the last upgrade with an old version
>> because it was under development. I think that it now should be fine
>> (upstream), ready to integrate.
>> There are possibly some other functions that are only half ways finished.
>> For instance 'snd-phasevocoder' is only a stub version in Audacity and
>> should as such be disabled until we move to Nyquist 3.10 or so.
>>
>> Robert
>>
>>> Steve
>>>
>>>>
>>>> Robert
>>>>
>>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>>>>> I would expect Nyquist to be most modified for Audacity in the area of
>>>>>> audio output since Audacity should "own" audio output. It seems like a
>>>>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>>>>
>>>>>> All the stuff I described for queries and specifying the preferred
>>>>>> audio
>>>>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
>>>>>> the code used for building Nyquist in Audacity.  Specifically look for
>>>>>>
>>>>>>         if (list) {
>>>>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>>>>                            device_info->name, host_info->name);
>>>>>>         }
>>>>>
>>>>>
>>>>> That's interesting - those lines do not exist, but what there is in
>>>>> sndwritepa.c is:
>>>>>
>>>>> // Initialize the audio stream for output
>>>>> // If this is Linux, prefer to open ALSA device
>>>>> num_devices = Pa_GetDeviceCount();
>>>>> for (i = 0; i < num_devices; i++) {
>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>    if (host_info->type == paALSA) {
>>>>>       output_parameters.device = i;
>>>>>       break;
>>>>>    }
>>>>> }
>>>>>
>>>>>
>>>>> and if I remove the special case for Linux:
>>>>>
>>>>> num_devices = Pa_GetDeviceCount();
>>>>> for (i = 0; i < num_devices; i++) {
>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>    // if (host_info->type == paALSA) {
>>>>>    //    output_parameters.device = i;
>>>>>    //    break;
>>>>>    //}
>>>>> }
>>>>>
>>>>> Then Nyquist does indeed use Pulse.
>>>>>
>>>>> Ah, just a moment - looking in the source for standalone Nyquist I see:
>>>>>
>>>>> // giving preference to first ALSA device seems to be a bad idea
>>>>> // if (j == -1 && host_info->type == paALSA) {
>>>>> //     j = i;
>>>>> // }
>>>>>
>>>>> So it looks like you fixed this problem in Nyquist some time ago, but
>>>>> in Audacity this code has not been touched in at least 8 years.
>>>>>
>>>>> So, updating LVAL prepare_audio(...)
>>>>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>>>>
>>>>> I'm even less familiar with C than I am with C++, so would you be able
>>>>> to cast your expert eye over this Roger?
>>>>>
>>>>> Steve
>>>>>
>>>>>>
>>>>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>>>>> console output.
>>>>>>
>>>>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>>>>> ;; WARNING: if you invoke an external program to play files,
>>>>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>>>>> ;; sound device while it is playing a sound file and then
>>>>>>> ;; refuse to play anything. -RBD dec05
>>>>>> I think what this means is that if you try to play through PortAudio
>>>>>> with Nyquist and Nyquist fails to open the audio device because it is
>>>>>> locked by something else, Nyquist might have problems. I'm not sure
>>>>>> what
>>>>>> this is about, but I can imagine Nyquist getting into some weird state
>>>>>> if it's all set to play audio and then encounters errors -- it's not a
>>>>>> normal situation, but I should check this out and improve error
>>>>>> recovery.
>>>>>>
>>>>>> -Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Stevethefiddle
Currently in Audacity, Nyquist plays through the system default device
on Windows and Mac, and the ALSA device on Linux.
In standalone Nyquist, the special case for Linux has been removed, so
the system default device is used on all platforms.

Standalone Nyquist has two additional features:
1) By setting *snd-list-devices* to true, the list of available
devices is printed.
2) A device may be specified for playback by setting the integer value
of *snd-device*

On Windows and Mac, if Nyquist's default output device follows the
Audacity setting, then as long as sound works in Audacity, it should
also work for Nyquist.

On Linux, that's not such a good idea because many users use ALSA
rather than the system default (PulseAudio) because of the P2 bug of
freezing with PulseAudio, but ALSA has an additional limitation for
Nyquist which is that it only supports sample rates that are directly
supported by the hardware. Audacity playback does not have this
problem because it can resample to a supported rate if necessary, but
Nyquist doesn't have that talent. On the other hand, the system
default seems to work very well for Nyquist.

My current thinking is that by default, Nyquist should follow
Audacity's device setting on Windows and Mac, and use the system
default on Linux. This works well on my hardware, but needs wider
testing, which we can only get by trying it.

Steve

On 19 June 2017 at 14:33, Robert Hänggi <[hidden email]> wrote:

> I don't understand the last point.
>
> Does it mean that Nyquist assumes that it sends the output to Alsa but
> in reality Audacity's default device--whatever it is--is used?
>
> Robert
>
> On 19/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> On 17 June 2017 at 07:20, Robert Hänggi <[hidden email]> wrote:
>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>> On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]> wrote:
>>>>> Bravo Steve
>>>>> It seems that you're finally making some headway.
>>>>
>>>> Thanks Robert. It's working terrifically on my machine.
>>>>
>>>> By default Nyquist uses PulseAudio, which is the system default
>>>> output, and the default for Audacity.
>>>>
>>>> With the default, Nyquist can play, or in the case of your accessible
>>>> plug-in it can talk, even if other applications are playing. This is
>>>> good news as it probably means (not tested yet) that it will work
>>>> while Orca screen reader is active. It also solves the problem with
>>>> playing oddball sample rates because PulseAudio can resample to a
>>>> supported rate on the fly.
>>>>
>>>> With the aid of *snd-list-devices* and *snd-device* it is also
>>>> possible to set Nyquist to play directly through Jack Audio System (if
>>>> Jack is running), and that is "proper" jack playback, not piped
>>>> through PulseAudio. I  don't think that we can make much practical use
>>>> of device selection in mainstream plug-ins, but it's terrific for
>>>> experimenting.
>>>>
>>>> A possible refinement would be for Nyquist to prefer Jack if Jack is
>>>> running, but I'm not overly concerned about that as (1) Nyquist will
>>>> prefer Jack if Jack is the system default, (2) If Pulse is the system
>>>> default and the user is using Jack, they will probably ("should") have
>>>> module-jack-sink set up for non-jack applications.
>>>>
>>>> I'm not sure what the policy / etiquette is for modifying libnyquist.
>>>> Normally we try to avoid modifying libraries, but libnyquist is a bit
>>>> of a special case as I think Audacity is the only application that
>>>> uses libnyquist, and the file in question is currently different from
>>>> the upstream (standalone) version. It's probably a matter for Roger to
>>>> decide.
>>>>
>>>
>>> It is certainly cool that the accessible plug-ins will work with Orca
>>> (very likely) since the screen reader doesn't support custom scripts.
>>>
>>> Is a comparable improvement achievable for the Mac?
>>> I think it's the worst of the three platforms as it never played sound at
>>> all.
>>
>> I've now tested on Mac, and I don't think that statement is completely
>> correct. Testing of Sierra, Nyquist playbacks does work, but there is
>> no indication of what output device is being used. If, as happened
>> during my testing, the default output device is turned off, then it
>> appears there is no playback. The proposed patch to sndwrite.pa is
>> very helpful for resolving this problem as you can set
>> *snd-list-devices* to 'true' and Nyquist will report which devices are
>> available and which is currently selected.
>>
>> This is probably a good case for implementing Roger's suggestion of
>> making the default device for Nyquist the same as Audacity's selected
>> output. To do that, we would need to playback  from Nyquist through
>> ALSA, but it looks like we can do that by reducing the default
>> latency.
>>
>> Steve
>>
>>>
>>> Apropos updating.
>>> We've replaced "convolve.c" in the last upgrade with an old version
>>> because it was under development. I think that it now should be fine
>>> (upstream), ready to integrate.
>>> There are possibly some other functions that are only half ways finished.
>>> For instance 'snd-phasevocoder' is only a stub version in Audacity and
>>> should as such be disabled until we move to Nyquist 3.10 or so.
>>>
>>> Robert
>>>
>>>> Steve
>>>>
>>>>>
>>>>> Robert
>>>>>
>>>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>>>>>> I would expect Nyquist to be most modified for Audacity in the area of
>>>>>>> audio output since Audacity should "own" audio output. It seems like a
>>>>>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>>>>>
>>>>>>> All the stuff I described for queries and specifying the preferred
>>>>>>> audio
>>>>>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure that's
>>>>>>> the code used for building Nyquist in Audacity.  Specifically look for
>>>>>>>
>>>>>>>         if (list) {
>>>>>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>>>>>                            device_info->name, host_info->name);
>>>>>>>         }
>>>>>>
>>>>>>
>>>>>> That's interesting - those lines do not exist, but what there is in
>>>>>> sndwritepa.c is:
>>>>>>
>>>>>> // Initialize the audio stream for output
>>>>>> // If this is Linux, prefer to open ALSA device
>>>>>> num_devices = Pa_GetDeviceCount();
>>>>>> for (i = 0; i < num_devices; i++) {
>>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>>    if (host_info->type == paALSA) {
>>>>>>       output_parameters.device = i;
>>>>>>       break;
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> and if I remove the special case for Linux:
>>>>>>
>>>>>> num_devices = Pa_GetDeviceCount();
>>>>>> for (i = 0; i < num_devices; i++) {
>>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>>    // if (host_info->type == paALSA) {
>>>>>>    //    output_parameters.device = i;
>>>>>>    //    break;
>>>>>>    //}
>>>>>> }
>>>>>>
>>>>>> Then Nyquist does indeed use Pulse.
>>>>>>
>>>>>> Ah, just a moment - looking in the source for standalone Nyquist I see:
>>>>>>
>>>>>> // giving preference to first ALSA device seems to be a bad idea
>>>>>> // if (j == -1 && host_info->type == paALSA) {
>>>>>> //     j = i;
>>>>>> // }
>>>>>>
>>>>>> So it looks like you fixed this problem in Nyquist some time ago, but
>>>>>> in Audacity this code has not been touched in at least 8 years.
>>>>>>
>>>>>> So, updating LVAL prepare_audio(...)
>>>>>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>>>>>
>>>>>> I'm even less familiar with C than I am with C++, so would you be able
>>>>>> to cast your expert eye over this Roger?
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>>
>>>>>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>>>>>> console output.
>>>>>>>
>>>>>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>>>>>> ;; WARNING: if you invoke an external program to play files,
>>>>>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>>>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>>>>>> ;; sound device while it is playing a sound file and then
>>>>>>>> ;; refuse to play anything. -RBD dec05
>>>>>>> I think what this means is that if you try to play through PortAudio
>>>>>>> with Nyquist and Nyquist fails to open the audio device because it is
>>>>>>> locked by something else, Nyquist might have problems. I'm not sure
>>>>>>> what
>>>>>>> this is about, but I can imagine Nyquist getting into some weird state
>>>>>>> if it's all set to play audio and then encounters errors -- it's not a
>>>>>>> normal situation, but I should check this out and improve error
>>>>>>> recovery.
>>>>>>>
>>>>>>> -Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Robert Hänggi
Ok, now it makes more sense.

It is strange that Gale didn't have any output on the Mac, last time
he tried (Wasn't on Sierra, of course).

Can you run a test with Orca turned on?

I would simply import a song and enter "(s-save *track* ny:all ""
:play t)" in the nyquist prompt. The rate should be fine, I think.
Since a song is somewhat longish, the progress dialog will probably
pop up and Orca may speak its content.
There are of course different combinations possible.

In general, one should avoid odd sample rates or resample in Nyquist
itself in order to be on the safe side.

Thx
Robert

On 19/06/2017, Steve the Fiddle <[hidden email]> wrote:

> Currently in Audacity, Nyquist plays through the system default device
> on Windows and Mac, and the ALSA device on Linux.
> In standalone Nyquist, the special case for Linux has been removed, so
> the system default device is used on all platforms.
>
> Standalone Nyquist has two additional features:
> 1) By setting *snd-list-devices* to true, the list of available
> devices is printed.
> 2) A device may be specified for playback by setting the integer value
> of *snd-device*
>
> On Windows and Mac, if Nyquist's default output device follows the
> Audacity setting, then as long as sound works in Audacity, it should
> also work for Nyquist.
>
> On Linux, that's not such a good idea because many users use ALSA
> rather than the system default (PulseAudio) because of the P2 bug of
> freezing with PulseAudio, but ALSA has an additional limitation for
> Nyquist which is that it only supports sample rates that are directly
> supported by the hardware. Audacity playback does not have this
> problem because it can resample to a supported rate if necessary, but
> Nyquist doesn't have that talent. On the other hand, the system
> default seems to work very well for Nyquist.
>
> My current thinking is that by default, Nyquist should follow
> Audacity's device setting on Windows and Mac, and use the system
> default on Linux. This works well on my hardware, but needs wider
> testing, which we can only get by trying it.
>
> Steve
>
> On 19 June 2017 at 14:33, Robert Hänggi <[hidden email]> wrote:
>> I don't understand the last point.
>>
>> Does it mean that Nyquist assumes that it sends the output to Alsa but
>> in reality Audacity's default device--whatever it is--is used?
>>
>> Robert
>>
>> On 19/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> On 17 June 2017 at 07:20, Robert Hänggi <[hidden email]> wrote:
>>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>> On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]>
>>>>> wrote:
>>>>>> Bravo Steve
>>>>>> It seems that you're finally making some headway.
>>>>>
>>>>> Thanks Robert. It's working terrifically on my machine.
>>>>>
>>>>> By default Nyquist uses PulseAudio, which is the system default
>>>>> output, and the default for Audacity.
>>>>>
>>>>> With the default, Nyquist can play, or in the case of your accessible
>>>>> plug-in it can talk, even if other applications are playing. This is
>>>>> good news as it probably means (not tested yet) that it will work
>>>>> while Orca screen reader is active. It also solves the problem with
>>>>> playing oddball sample rates because PulseAudio can resample to a
>>>>> supported rate on the fly.
>>>>>
>>>>> With the aid of *snd-list-devices* and *snd-device* it is also
>>>>> possible to set Nyquist to play directly through Jack Audio System (if
>>>>> Jack is running), and that is "proper" jack playback, not piped
>>>>> through PulseAudio. I  don't think that we can make much practical use
>>>>> of device selection in mainstream plug-ins, but it's terrific for
>>>>> experimenting.
>>>>>
>>>>> A possible refinement would be for Nyquist to prefer Jack if Jack is
>>>>> running, but I'm not overly concerned about that as (1) Nyquist will
>>>>> prefer Jack if Jack is the system default, (2) If Pulse is the system
>>>>> default and the user is using Jack, they will probably ("should") have
>>>>> module-jack-sink set up for non-jack applications.
>>>>>
>>>>> I'm not sure what the policy / etiquette is for modifying libnyquist.
>>>>> Normally we try to avoid modifying libraries, but libnyquist is a bit
>>>>> of a special case as I think Audacity is the only application that
>>>>> uses libnyquist, and the file in question is currently different from
>>>>> the upstream (standalone) version. It's probably a matter for Roger to
>>>>> decide.
>>>>>
>>>>
>>>> It is certainly cool that the accessible plug-ins will work with Orca
>>>> (very likely) since the screen reader doesn't support custom scripts.
>>>>
>>>> Is a comparable improvement achievable for the Mac?
>>>> I think it's the worst of the three platforms as it never played sound
>>>> at
>>>> all.
>>>
>>> I've now tested on Mac, and I don't think that statement is completely
>>> correct. Testing of Sierra, Nyquist playbacks does work, but there is
>>> no indication of what output device is being used. If, as happened
>>> during my testing, the default output device is turned off, then it
>>> appears there is no playback. The proposed patch to sndwrite.pa is
>>> very helpful for resolving this problem as you can set
>>> *snd-list-devices* to 'true' and Nyquist will report which devices are
>>> available and which is currently selected.
>>>
>>> This is probably a good case for implementing Roger's suggestion of
>>> making the default device for Nyquist the same as Audacity's selected
>>> output. To do that, we would need to playback  from Nyquist through
>>> ALSA, but it looks like we can do that by reducing the default
>>> latency.
>>>
>>> Steve
>>>
>>>>
>>>> Apropos updating.
>>>> We've replaced "convolve.c" in the last upgrade with an old version
>>>> because it was under development. I think that it now should be fine
>>>> (upstream), ready to integrate.
>>>> There are possibly some other functions that are only half ways
>>>> finished.
>>>> For instance 'snd-phasevocoder' is only a stub version in Audacity and
>>>> should as such be disabled until we move to Nyquist 3.10 or so.
>>>>
>>>> Robert
>>>>
>>>>> Steve
>>>>>
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>>>>>>> I would expect Nyquist to be most modified for Audacity in the area
>>>>>>>> of
>>>>>>>> audio output since Audacity should "own" audio output. It seems like
>>>>>>>> a
>>>>>>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>>>>>>
>>>>>>>> All the stuff I described for queries and specifying the preferred
>>>>>>>> audio
>>>>>>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure
>>>>>>>> that's
>>>>>>>> the code used for building Nyquist in Audacity.  Specifically look
>>>>>>>> for
>>>>>>>>
>>>>>>>>         if (list) {
>>>>>>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>>>>>>                            device_info->name, host_info->name);
>>>>>>>>         }
>>>>>>>
>>>>>>>
>>>>>>> That's interesting - those lines do not exist, but what there is in
>>>>>>> sndwritepa.c is:
>>>>>>>
>>>>>>> // Initialize the audio stream for output
>>>>>>> // If this is Linux, prefer to open ALSA device
>>>>>>> num_devices = Pa_GetDeviceCount();
>>>>>>> for (i = 0; i < num_devices; i++) {
>>>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>>>    if (host_info->type == paALSA) {
>>>>>>>       output_parameters.device = i;
>>>>>>>       break;
>>>>>>>    }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> and if I remove the special case for Linux:
>>>>>>>
>>>>>>> num_devices = Pa_GetDeviceCount();
>>>>>>> for (i = 0; i < num_devices; i++) {
>>>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>>>    // if (host_info->type == paALSA) {
>>>>>>>    //    output_parameters.device = i;
>>>>>>>    //    break;
>>>>>>>    //}
>>>>>>> }
>>>>>>>
>>>>>>> Then Nyquist does indeed use Pulse.
>>>>>>>
>>>>>>> Ah, just a moment - looking in the source for standalone Nyquist I
>>>>>>> see:
>>>>>>>
>>>>>>> // giving preference to first ALSA device seems to be a bad idea
>>>>>>> // if (j == -1 && host_info->type == paALSA) {
>>>>>>> //     j = i;
>>>>>>> // }
>>>>>>>
>>>>>>> So it looks like you fixed this problem in Nyquist some time ago, but
>>>>>>> in Audacity this code has not been touched in at least 8 years.
>>>>>>>
>>>>>>> So, updating LVAL prepare_audio(...)
>>>>>>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>>>>>>
>>>>>>> I'm even less familiar with C than I am with C++, so would you be
>>>>>>> able
>>>>>>> to cast your expert eye over this Roger?
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>>
>>>>>>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>>>>>>> console output.
>>>>>>>>
>>>>>>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>>>>>>> ;; WARNING: if you invoke an external program to play files,
>>>>>>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>>>>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>>>>>>> ;; sound device while it is playing a sound file and then
>>>>>>>>> ;; refuse to play anything. -RBD dec05
>>>>>>>> I think what this means is that if you try to play through PortAudio
>>>>>>>> with Nyquist and Nyquist fails to open the audio device because it
>>>>>>>> is
>>>>>>>> locked by something else, Nyquist might have problems. I'm not sure
>>>>>>>> what
>>>>>>>> this is about, but I can imagine Nyquist getting into some weird
>>>>>>>> state
>>>>>>>> if it's all set to play audio and then encounters errors -- it's not
>>>>>>>> a
>>>>>>>> normal situation, but I should check this out and improve error
>>>>>>>> recovery.
>>>>>>>>
>>>>>>>> -Roger
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PulseAudio support for Nyquist

Stevethefiddle
Orca uses PulseAudio by default, and PulseAudio supports multiple
clients, so yes, Nyquist playback and Orca speech can happen at the
same time if Nyquist is using PulseAudio, but not if Nyquist is using
ALSA.

Steve

On 19 June 2017 at 15:37, Robert Hänggi <[hidden email]> wrote:

> Ok, now it makes more sense.
>
> It is strange that Gale didn't have any output on the Mac, last time
> he tried (Wasn't on Sierra, of course).
>
> Can you run a test with Orca turned on?
>
> I would simply import a song and enter "(s-save *track* ny:all ""
> :play t)" in the nyquist prompt. The rate should be fine, I think.
> Since a song is somewhat longish, the progress dialog will probably
> pop up and Orca may speak its content.
> There are of course different combinations possible.
>
> In general, one should avoid odd sample rates or resample in Nyquist
> itself in order to be on the safe side.
>
> Thx
> Robert
>
> On 19/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> Currently in Audacity, Nyquist plays through the system default device
>> on Windows and Mac, and the ALSA device on Linux.
>> In standalone Nyquist, the special case for Linux has been removed, so
>> the system default device is used on all platforms.
>>
>> Standalone Nyquist has two additional features:
>> 1) By setting *snd-list-devices* to true, the list of available
>> devices is printed.
>> 2) A device may be specified for playback by setting the integer value
>> of *snd-device*
>>
>> On Windows and Mac, if Nyquist's default output device follows the
>> Audacity setting, then as long as sound works in Audacity, it should
>> also work for Nyquist.
>>
>> On Linux, that's not such a good idea because many users use ALSA
>> rather than the system default (PulseAudio) because of the P2 bug of
>> freezing with PulseAudio, but ALSA has an additional limitation for
>> Nyquist which is that it only supports sample rates that are directly
>> supported by the hardware. Audacity playback does not have this
>> problem because it can resample to a supported rate if necessary, but
>> Nyquist doesn't have that talent. On the other hand, the system
>> default seems to work very well for Nyquist.
>>
>> My current thinking is that by default, Nyquist should follow
>> Audacity's device setting on Windows and Mac, and use the system
>> default on Linux. This works well on my hardware, but needs wider
>> testing, which we can only get by trying it.
>>
>> Steve
>>
>> On 19 June 2017 at 14:33, Robert Hänggi <[hidden email]> wrote:
>>> I don't understand the last point.
>>>
>>> Does it mean that Nyquist assumes that it sends the output to Alsa but
>>> in reality Audacity's default device--whatever it is--is used?
>>>
>>> Robert
>>>
>>> On 19/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>> On 17 June 2017 at 07:20, Robert Hänggi <[hidden email]> wrote:
>>>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>> On 16 June 2017 at 06:19, Robert Hänggi <[hidden email]>
>>>>>> wrote:
>>>>>>> Bravo Steve
>>>>>>> It seems that you're finally making some headway.
>>>>>>
>>>>>> Thanks Robert. It's working terrifically on my machine.
>>>>>>
>>>>>> By default Nyquist uses PulseAudio, which is the system default
>>>>>> output, and the default for Audacity.
>>>>>>
>>>>>> With the default, Nyquist can play, or in the case of your accessible
>>>>>> plug-in it can talk, even if other applications are playing. This is
>>>>>> good news as it probably means (not tested yet) that it will work
>>>>>> while Orca screen reader is active. It also solves the problem with
>>>>>> playing oddball sample rates because PulseAudio can resample to a
>>>>>> supported rate on the fly.
>>>>>>
>>>>>> With the aid of *snd-list-devices* and *snd-device* it is also
>>>>>> possible to set Nyquist to play directly through Jack Audio System (if
>>>>>> Jack is running), and that is "proper" jack playback, not piped
>>>>>> through PulseAudio. I  don't think that we can make much practical use
>>>>>> of device selection in mainstream plug-ins, but it's terrific for
>>>>>> experimenting.
>>>>>>
>>>>>> A possible refinement would be for Nyquist to prefer Jack if Jack is
>>>>>> running, but I'm not overly concerned about that as (1) Nyquist will
>>>>>> prefer Jack if Jack is the system default, (2) If Pulse is the system
>>>>>> default and the user is using Jack, they will probably ("should") have
>>>>>> module-jack-sink set up for non-jack applications.
>>>>>>
>>>>>> I'm not sure what the policy / etiquette is for modifying libnyquist.
>>>>>> Normally we try to avoid modifying libraries, but libnyquist is a bit
>>>>>> of a special case as I think Audacity is the only application that
>>>>>> uses libnyquist, and the file in question is currently different from
>>>>>> the upstream (standalone) version. It's probably a matter for Roger to
>>>>>> decide.
>>>>>>
>>>>>
>>>>> It is certainly cool that the accessible plug-ins will work with Orca
>>>>> (very likely) since the screen reader doesn't support custom scripts.
>>>>>
>>>>> Is a comparable improvement achievable for the Mac?
>>>>> I think it's the worst of the three platforms as it never played sound
>>>>> at
>>>>> all.
>>>>
>>>> I've now tested on Mac, and I don't think that statement is completely
>>>> correct. Testing of Sierra, Nyquist playbacks does work, but there is
>>>> no indication of what output device is being used. If, as happened
>>>> during my testing, the default output device is turned off, then it
>>>> appears there is no playback. The proposed patch to sndwrite.pa is
>>>> very helpful for resolving this problem as you can set
>>>> *snd-list-devices* to 'true' and Nyquist will report which devices are
>>>> available and which is currently selected.
>>>>
>>>> This is probably a good case for implementing Roger's suggestion of
>>>> making the default device for Nyquist the same as Audacity's selected
>>>> output. To do that, we would need to playback  from Nyquist through
>>>> ALSA, but it looks like we can do that by reducing the default
>>>> latency.
>>>>
>>>> Steve
>>>>
>>>>>
>>>>> Apropos updating.
>>>>> We've replaced "convolve.c" in the last upgrade with an old version
>>>>> because it was under development. I think that it now should be fine
>>>>> (upstream), ready to integrate.
>>>>> There are possibly some other functions that are only half ways
>>>>> finished.
>>>>> For instance 'snd-phasevocoder' is only a stub version in Audacity and
>>>>> should as such be disabled until we move to Nyquist 3.10 or so.
>>>>>
>>>>> Robert
>>>>>
>>>>>> Steve
>>>>>>
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>> On 16/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>>> On 15 June 2017 at 21:55, Roger Dannenberg <[hidden email]> wrote:
>>>>>>>>> I would expect Nyquist to be most modified for Audacity in the area
>>>>>>>>> of
>>>>>>>>> audio output since Audacity should "own" audio output. It seems like
>>>>>>>>> a
>>>>>>>>> bug (or unanticipated "feature") that Nyquist can do output at all.
>>>>>>>>>
>>>>>>>>> All the stuff I described for queries and specifying the preferred
>>>>>>>>> audio
>>>>>>>>> device for Nyquist is in nyqsrc/sndwritepa.c, but I'm not sure
>>>>>>>>> that's
>>>>>>>>> the code used for building Nyquist in Audacity.  Specifically look
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>>         if (list) {
>>>>>>>>>             nyquist_printf("PortAudio %d: %s -- %s\n", i,
>>>>>>>>>                            device_info->name, host_info->name);
>>>>>>>>>         }
>>>>>>>>
>>>>>>>>
>>>>>>>> That's interesting - those lines do not exist, but what there is in
>>>>>>>> sndwritepa.c is:
>>>>>>>>
>>>>>>>> // Initialize the audio stream for output
>>>>>>>> // If this is Linux, prefer to open ALSA device
>>>>>>>> num_devices = Pa_GetDeviceCount();
>>>>>>>> for (i = 0; i < num_devices; i++) {
>>>>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>>>>    if (host_info->type == paALSA) {
>>>>>>>>       output_parameters.device = i;
>>>>>>>>       break;
>>>>>>>>    }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> and if I remove the special case for Linux:
>>>>>>>>
>>>>>>>> num_devices = Pa_GetDeviceCount();
>>>>>>>> for (i = 0; i < num_devices; i++) {
>>>>>>>>    device_info = Pa_GetDeviceInfo(i);
>>>>>>>>    host_info = Pa_GetHostApiInfo(device_info->hostApi);
>>>>>>>>    // if (host_info->type == paALSA) {
>>>>>>>>    //    output_parameters.device = i;
>>>>>>>>    //    break;
>>>>>>>>    //}
>>>>>>>> }
>>>>>>>>
>>>>>>>> Then Nyquist does indeed use Pulse.
>>>>>>>>
>>>>>>>> Ah, just a moment - looking in the source for standalone Nyquist I
>>>>>>>> see:
>>>>>>>>
>>>>>>>> // giving preference to first ALSA device seems to be a bad idea
>>>>>>>> // if (j == -1 && host_info->type == paALSA) {
>>>>>>>> //     j = i;
>>>>>>>> // }
>>>>>>>>
>>>>>>>> So it looks like you fixed this problem in Nyquist some time ago, but
>>>>>>>> in Audacity this code has not been touched in at least 8 years.
>>>>>>>>
>>>>>>>> So, updating LVAL prepare_audio(...)
>>>>>>>> https://github.com/SteveDaulton/audacity/commit/e71e8f4461d2e7
>>>>>>>>
>>>>>>>> I'm even less familiar with C than I am with C++, so would you be
>>>>>>>> able
>>>>>>>> to cast your expert eye over this Roger?
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>>
>>>>>>>>> which is in sndwritepa.c and where devices get listed to the Nyquist
>>>>>>>>> console output.
>>>>>>>>>
>>>>>>>>> On 6/15/17 4:18 PM, Steve the Fiddle wrote:
>>>>>>>>>> ;; WARNING: if you invoke an external program to play files,
>>>>>>>>>> ;; but Nyquist uses internal (portaudio) interface to
>>>>>>>>>> ;; play synthesized sound, Nyquist may fail to open the
>>>>>>>>>> ;; sound device while it is playing a sound file and then
>>>>>>>>>> ;; refuse to play anything. -RBD dec05
>>>>>>>>> I think what this means is that if you try to play through PortAudio
>>>>>>>>> with Nyquist and Nyquist fails to open the audio device because it
>>>>>>>>> is
>>>>>>>>> locked by something else, Nyquist might have problems. I'm not sure
>>>>>>>>> what
>>>>>>>>> this is about, but I can imagine Nyquist getting into some weird
>>>>>>>>> state
>>>>>>>>> if it's all set to play audio and then encounters errors -- it's not
>>>>>>>>> a
>>>>>>>>> normal situation, but I should check this out and improve error
>>>>>>>>> recovery.
>>>>>>>>>
>>>>>>>>> -Roger
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...