Tue 20 Jan 2015 01:46:12 PM UTC, comment #21:
Just for info, since the last changes it passes the audio tests each time!
|
Thu 15 Jan 2015 08:42:49 PM UTC, comment #20:
I was f64cdbe11621 doc: Periodic spellcheck of documentation.
|
Thu 15 Jan 2015 08:28:35 PM UTC, comment #19:
Yes the destructor should be called. I made the following change to audiodevinfo.cc:
I do see the message from the destructor if I do
The destructor should be called even if the object is not currently recording, but I think stopping recording should only be needed if it is actually currently recording. What is your hg ID? Mine is
|
Thu 15 Jan 2015 01:18:22 PM UTC, comment #18:
I haven't has much to do with creating own types in octave, but when I have:
a = audiorecorder
a = audiorecorder
shouldn't the deconstructor of the octave value of the old 'a' be called?
If I change the code to print something out whenever Pa_StoStream is called, only one case in the tests calls stop, and that's when multiple records are called on the same audio recorder. Which is probally why the tests work if I call stop explicitly in the octave code.
If I also add a print in the deconstructor of the audiorecorder c++ object, I never see it printed out - originally I though adding a stop in the c++ code at the end of recordblocking, and one in the deconstructor if it has a valid stream would be needed.
|
Wed 14 Jan 2015 05:49:02 PM UTC, comment #17:
If I add a call to stop(recorder) after each test in the audiorecorder.m tests that calls record or recordblocking, then I appear to be consistently passing the audio tests.
|
Wed 14 Jan 2015 05:06:12 PM UTC, comment #16:
Should audiorecorder::recordblocking call Pa_StopStream after getting the required data?
Just running the 1st test the audio recorder tests repeatedly would some times fail being able to open the audio device.
If I call stop(recorder) after the test, it allows me to repeatedly run the 1st test without fails.
|
Wed 14 Jan 2015 03:06:42 PM UTC, comment #15:
Windows build from:
No more crashes for me, however audioplayer and autorecorder tests runs sometimes pass, sometimes do not.
Log reports errors such as:
|
Wed 14 Jan 2015 01:37:11 PM UTC, comment #14:
lablab would be octave :)
|
Wed 14 Jan 2015 01:36:23 PM UTC, comment #13:
For info, on my lablab version currently:
|
Wed 14 Jan 2015 11:50:43 AM UTC, comment #12:
I used the test program that is created in portaudio.mk as thought that would verify that the portaudio library actually finds things ok.
It doesnt get installed though - I grabbed it when compiling the library.
|
Wed 14 Jan 2015 04:08:29 AM UTC, comment #11:
I checked in some more changes for the audio functions. Now I don't get crashes when running the tests, but the system I'm using for testing doesn't pass the tests because Octve isn't finding any audio input devices. I don't know if that's a bug in Octave or that the system actually doesn't have any audio input devices. How can I check that with a Windows utility?
|
Tue 13 Jan 2015 09:46:51 PM UTC, comment #10:
There have been a couple of audio changes made since I built for mxe last, so will try with them.
|
Tue 13 Jan 2015 09:43:58 PM UTC, comment #9:
No - still crashes most times.
Also, callbacks are not implemented for the audio, so those last 2 tests wont work anyway (removing them doesn't stop the crash)
|
Tue 13 Jan 2015 09:37:40 PM UTC, comment #8:
I'd say yes, in that test we should be stopping the recorder.
If you make that change, does it avoid the problem?
But even so, Octave should not crash.
|
Tue 13 Jan 2015 09:07:29 PM UTC, comment #7:
Running it a couple of times, it occasionally will pass the recorder tests.
In line 129 of audiorecorder.m, is it supposed to be "stop(recorder)" ?
|
Tue 13 Jan 2015 06:45:09 PM UTC, comment #6:
I built gdb and added it to the install and ran the tests with gdb. I forgot to skip the strip step, but I still found that it crashed at line 1511 of audiodevinfo.cc. That line is
so I'm guessing Pa_GetDeviceInfo is returning NULL.
I also see that we sometimes check the number returned from Pa_GetDeviceCount < 0 and other times < 1. What's the right thing? In any case, we need to be more defensive with the pointers that we grab from portaudio... I think I can work on this a bit more later today.
|
Tue 13 Jan 2015 05:40:02 PM UTC, comment #5:
I had played audio ok - but hadn't run with test suite.
On running test suite,
I get audioplayer.m pass 5/6
audiorecoder.m: crashes
|
Tue 13 Jan 2015 05:26:16 PM UTC, comment #4:
Have you tried _run_test_suite_? Does it work for you? I tried with mxe-octave hg id
80b2b5cfde0f tip @
and octave hg id
62ca016dbb2a tip @
and it crashes during one of the audio tests. It does play some sounds so at least some audio features are working, but then crashes.
|
Tue 13 Jan 2015 02:39:38 PM UTC, comment #3:
Thanks - closing bug with a successful build for Windows
|
Fri 09 Jan 2015 08:52:20 PM UTC, comment #2:
I pushed your changeset.
Thanks.
|
Fri 09 Jan 2015 06:55:01 PM UTC, comment #1:
Patch attached changing audio_type enum names to TYPE_XXXX.
(file #32801)
|
Fri 09 Jan 2015 06:26:31 PM UTC, original submission:
Currently failing at because UINT8, INT8 etc are already defined.
|