No sound when running test.rs example

[niclashoyer]

I just tried the example test.rs, but it seems that immediately after printing note_on it exits. Some debug logging reveals that audio_requested is called exactly two times and after that the process exits with a buffer underrun. The synth is active and the output buffer in audio_requested is filled with values (different from zero). Any suggestions for debugging?

Example output:

ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
It begins!
note_on
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
Breaking from loop as sound_stream failed to write to the PortAudio stream: OutputUnderflowed.
Great success!

[mitchmindtree]

Hmmm, definitely an issue (you should hear a sine wave sweeping downward for about 3 seconds) - it's running fine on macos for me, however this isn't the first time a linux user has reported buffer under/overflow issues!

Do the rust-portaudio examples work for you? When you run them, it should pass the input straight to the output (so you should be able to hear mic input coming from your speakers). I would be interested to hear how both the non-blocking and blocking examples run - I have a feeling our problem might be in the rust-portaudio crate (perhaps we still have to implement some system-specific stuff for ALSA / Jack).

Btw, does changing the channels in the example make any difference? It probably won't, but worth a try as portaudio doesn't seem to be able to find a matching channel map (I think the problem is probably deeper though).

So sorry you've been running into issues with the RustAudio crates! I really appreciate you sharing these issues, and I'm really keen to see what we can do to fix them!

PS: Actually come to think of it, I should also mention that when I first run rust-portaudio's stream.start() on macos, I get buffer underflow for about 50 buffers and then after that it never occurs again, however in my case the stream doesn't return an error - perhaps the ALSA blocking implementation within the portaudio C lib returns an error in this case, whereas the coreaudio implementation doesn't? That could be why sound_stream panics for you but not for me?

If this is the case, I think we could fix it by changing SoundStream to return an Event::Error(err, action) (rather than just panic!ing) where action defaults to ErrorAction::BreakFromLoop, however a user can pattern match on the error and (in the case that some under/overrun has occurred) change it to ErrorAction::Ignore (i.e. *action = ErrorAction::Ignore or action(ErrorAction::Ignore)).

[niclashoyer]

Changing the channels did not help. I just ran the examples from rust-portaudio again. Indeed, the blocking example shows the same behavior, it immediately exits. The non blocking example however, just works fine. Also, I do not encounter any underflows.

I pasted the output to this gist.

[mitchmindtree]

@niclashoyer I think this might have been a fix - let me know how cargo update; cargo run --example test goes.

[niclashoyer]

With the changes in portaudio#76 and sound_stream# the test finally runs on my laptop using ALSA.

Using the debug build I get a lot of underruns and very distorted sound. Running with --release shows less underruns, but I think the sine wave sweeps too fast, but as this is very subjective I just recorded samples 😄
the "crackling" sound corresponds to underrun messages in the console

[mitchmindtree]

Unfortunately these samples aren't working for me (it just takes me to a privacy error page) - any chance try a different host? or you could email them to me - mitchell dot nordine at gmail dot com. (Would be nice to have them on this issue for reference though). I should really add a simple 440hz sine wave example too so it's easier to test. Maybe you're up for adding this? I'll add an issue.

I'm not sure what could be causing the consistent underruns - might have to do some reading on the difference between the way portaudio handles streams between OSs. It might even be a difference between drivers as well.

Anyway, you mentioned that the non-blocking example works fine yes? I might add non-blocking support to SoundStream tonight so at least users have something usable to work with (it's also probably a more attractive option than a blocking stream in most cases anyway).

[mitchmindtree]

facepalm I think I figured out the issue with the blocking example. We should have been using the number of frames returned by get_read/write_stream_available - not the number of frames that you set the stream up with. Here's the PR. Fixing SoundStream now

[niclashoyer]

great! I'll test asap. Nevertheless I sent you the samples by email. I searched for something like gist or pastebin, but for sound files. I tried soundcloud, but they needed flash, so I thought why not upload it to my server. I forgot that my certificate is still self signed, sorry about that.

[niclashoyer]

As portaudio#78 fixed the blocking example for me on ALSA, does the sound_stream crate also need to handle async duplex streams differently? Because the examples are still failing for me with underruns.

[mitchmindtree]

i haven't yet updated SoundStream (the iterator method needs a pretty thorough re-write), should be done within an hour two though :)