bugGNU Octave - Bugs: bug #54668, unable to open audio recording...


bug #54668: unable to open audio recording stream

Submitted by:  John Price <jprice>
Submitted on:  Mon 17 Sep 2018 05:24:20 AM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Need Info Assigned to:  None
Originator Name:  John Price Open/Closed:  Open
Release:  4.4.1 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 27 Sep 2018 10:21:50 PM UTC, comment #6:

As a suggestion you can have a look at the playrec library at http://www.playrec.co.uk/index.html

It may provide a solution if the problem is in portaudio interfacing the Windows soundcard drivers. 

In addition to MME and DirectSound it can call the ASIO drivers available for most professional sound devices, which are often much more stable. And it is designed for simultanously reading and writing multicannel audio at all hardware supported samplerates with sample precise alignment, all of which is impossible to achieve with asynchronously combining the audiorecorder and audioplayer objects.  

Lars Kindermann <larskindermann>
Wed 26 Sep 2018 04:45:54 PM UTC, comment #5:

I have done some tests now with a different interface, the ART USB Dual Pre, still on a Win 7 system. This is a 2-channel in and out USB interface with XLR mic inputs. Data is 16 bits at 44100 or 48000 Hz. It works fine with the test code I posted here at both sampling rates, using device IDs for the MME drivers. The only oddity I see is a spurious click at the very end of the play output when the play time series ends. A work-around is to append about 1 second of zero samples at the end of the play time series. Latency is about 0.23 s. If I try to use the DirectSound drivers, I still get zeros in the data. I am not sure if that is to be expected or not.

So far, the tl;dr of this is that a 16 bit interface works and a 24 bit one does not.  I still want to do more tests of both the 16 bit and 24 bit interface on Win 10 to see if that is any different.

John Price <jprice>
Tue 18 Sep 2018 04:32:26 AM UTC, comment #4:

Mike, thanks again for these comments. I understand about the limited development support and am grateful for any info that can be provided. Great idea about trying the Audiobox 96 with Audacity. It does not work and shows similar problems as with Octave. Both Audacity and Octave work with the internal sound hardware. So I suspect that PortAudio cannot handle this 24-bit interface.

When I use the internal sound hardware with Audacity, I can use DirectSound drivers for both record and play. With Octave, the DirectSound driver works for play, but for recording the DirectSound driver gives zeros in the data. That could be a bug. Recording does work fine with the MME driver.

I think my next step should be to try my test code with the Audiobox and Win 10 to see if that is different. I will probably try to get some other hardware that is a USB audio interface with XLR mic inputs but that is 16 bits rather than 24. I suspect that might work. I am not sure if we can leave this thread open or not, but if we can I will report results of further tests.

John Price <jprice>
Mon 17 Sep 2018 11:34:39 PM UTC, comment #3:

Have you tried Audacity on this system? If not, can you try installing and testing it with the PortAudio interface? Does recording work correctly with the Audiobox?

If you change your script so that the host is only recording and not trying to play back simultaneously, does that increase the chance of success at all?

To answer the questions that I can,

> I don't know if this is being passed up from PortAudio or if it is coming from Octave.

The error message comes from Octave, but it is in direct response to the PortAudio function for opening an audio stream failing. So the question goes back to why is PortAudio returning failure to open a stream on this particular hardware with these particular settings?

> I also don't know what version of PortAudio is in Octave 4.4.1.

The Windows build of Octave is using the latest stable PortAudio release as shown on http://www.portaudio.com/download.html, version 190600_20161030.

Just to give you an idea of what to expect from us, the Octave developers, we have about 3 or 4 volunteers who have worked on the PortAudio interface over a few years, all testing on GNU/Linux systems, and probably all with basic onboard internal sound hardware. If the audio I/O functions work with PortAudio on Windows, then great, that's why we decided to go with PortAudio. But we are not audio device driver experts, nor are we PortAudio library experts. And we have no extensive testing capabilities or hardware compatibility requirements.

As the reporter of this bug with sole access to the specific hardware that causes this bug, I think this bug has to rely on more information from you helping to identify whether there is something specific in Octave's use of PortAudio that needs to be changed. Or perhaps that the use of PortAudio at all is insufficient for this use case or this hardware, maybe by comparing other programs you have access to, such as Audacity, that use PortAudio on Windows.

Mike Miller <mtmiller>
Project Administrator
Mon 17 Sep 2018 10:06:39 PM UTC, comment #2:

Thanks for responding Mike. Yes, that is correct, I can get the posted code to work with the built-in sound card on my desktop computer (HPZ420, Win7, Realtek sound). With the PreSonus Audiobox 96 I get the error "audiorecorder: unable to open audio recording stream" with MME drivers. I don't know if this is being passed up from PortAudio or if it is coming from Octave. I have had it work with the Audiobox and DirectSound drivers (in the sense that there are no error messages) but the recorded data is all zeros. That seems more like a problem with the Octave interface to PortAudio, but I am not sure. I did find on the Audacity site in a discussion about PortAudio they say that Windows DirectSound and MME do not support 24 bits, so perhaps that is the underlying problem. But these things are time-dependent and I don't know if this is true for the current version of the Windows drivers and the current version of PortAudio. I also don't know what version of PortAudio is in Octave 4.4.1.  It is a little over my head to try to look at the Octave code.

John Price <jprice>
Mon 17 Sep 2018 05:26:58 PM UTC, comment #1:

Thank you for your bug report. You are saying that your program is able to run, and you are able to get simultaneous play and record working on your system's internal sound card? But when you try a different sound device it does not work?

I think that suggests that Octave is doing everything correctly that it can to support simultaneous play and record, but there may be a problem at a lower level between the PortAudio library and the Windows device drivers for your hardware. Do you know if there is some evidence that Octave is not using the PortAudio library correctly to work with your hardware?

Mike Miller <mtmiller>
Project Administrator
Mon 17 Sep 2018 05:24:20 AM UTC, original submission:

I am not sure if this is a bug report or not. Maybe the behavior  I see is expected for experts, and I just need to be told what the implemented capabilities are. Code below shows what I am trying to do -- basically 2 channel in and 2 channel out simultaneous audio play and record.

My hardware is a PreSonus Audiobox 96, which supports quite a few bit rates but I think only 24 bit width. I cannot make it work -- typically it dies with "audiorecorder: unable to open audio recording stream". I have tried every combination of bit width and bit rate, also both MME and DirectSound device IDs. (audiodevinfo() returns device IDs for both). Sometimes it works for a while with the MME drivers, 16 bits, and 48000 sampling rate, but it is is not reliable. Sometimes it will run with 24 bits and the DirectSound drivers but the data it returns is all zeros.

I can make the internal sound card on my desktop (RealTek) work but I really need mic preamps with XLR inputs.

I could use other hardware, but it would be a big help if someone could tell me examples that will definitely work. I am using Win 7 but could try other options.

% script beeper.m





clear recorded recordedLeft recordedRight
for n = [1:5]


function recordseries=playAndRecord(playseries)
% interface test code
% use info=audiodevinfo() to get device IDs
% 16 bit MME seems to work, latency about
recID=8; recchan=2;     
playID=11; playchan=2;   

recduration = length(playseries)/fsamp;

recorder = audiorecorder(fsamp,bits,recchan,recID);
player = audioplayer(playseries,fsamp,bits,playID);

% record(recorder,recduration);    % not blocking version
while (isplaying(player))
% while (isplaying(player) || isrecording(recorder))  % not blocking version



John Price <jprice>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by larskindermann (Posted a comment)
  • -email is unavailable- added by jprice (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-19 mtmiller Carbon-CopyRemoved 80942 => -
    2018-09-17 mtmiller StatusNone => Need Info

    Back to the top

    Powered by Savane 3.4