Either the Sample device name changed or the routing with the Sample device broke

[hllf]

As of the commits on Mar 14, everything was working correctly. However, I just updated and grabbed the commits from the last 3 days, and the routing for playing samples broke. Now when I play a sample, I hear the sample through headphones, but it's not being routed to any other channel, even though the Sample -> Microphone route is checked.

In addition, if I go into the router and disable the Sample -> Headphones route, I still hear the sample being played through headphones, which I should not.

My guess is either the daemon is now looking for a different device name than Sample, or something else broke. I haven't had time to look through the code to diagnose. I did try running the daemon in debug log level, and I saw it did say it found device core\sample, so that makes me think the device name is not the issue.

Thanks!

[hllf]

Please note I'm running the daemon on macOS, if this makes a difference.

[FrostyCoolSlug]

Thanks, I did a pretty chunky refactor of the CPAL backend for sample playback the other day, I'm guessing that's broken something under MacOS.

I've just pushed a change which adds a bit of extra logging, could you please pull the latest change and start the daemon with --log-level debug, when you try to play a sample it should give details of the audio device it's attempting to play back through, or if it has problems finding it. Hopefully with that I can work out what went wrong.

Thanks.

[hllf]

Sure, I'll do so shortly and post results.

[hllf]

Attached is the full log. I did nothing but launch the daemon, hit my upper left sampler button, then killed. I do see a sampler device not found error, but I'm not sure if that's related, as the issue is not with the sampler device but ra log.txt ther the sample device for output. I haven't looked it in much detail though. Let me know what you think and what I can try next.

[FrostyCoolSlug]

The device not found error was the debug I put in, it's curious, because the first pass check finds it, but the second pass doesn't.. I've pushed another change with even more debug, can you give that a run for me please?

The same test is fine.

Thanks.

[hllf]

Sure, new log is attached. log.txt

[FrostyCoolSlug]

Sorry, can you do with with --log-level debug again please?

[hllf]

Sorry I'm an idiot, I'll do it again right now.

[hllf]

Correct log file attached with debug log level. log.txt

[FrostyCoolSlug]

Thanks! I see the problem:

06:18:10 [DEBUG] (33) goxlr_audio::cpal::cpal_config: Checking Device: Sample
06:18:10 [DEBUG] (33) goxlr_audio::cpal::cpal_config: This device is Input, looking for Output

I'm guessing this is related to aggregate devices as they can be both inputs and outputs simultaniously. I've pushed a tentative fix for this (if a Device displays both input and output characteristics, don't do additional type checking), could you give that a try for me please?

Thanks

[hllf]

Yup, I was just about to comment that base don the log, it is seeing every virtual device as an input device.

I'm running the update now; will report back in a moment.

[hllf]

That fixed it!

Unfortunately, however, it introduced a new issue or at least made one come to the surface. Now if I hit a sample button, then while the sample is playing, hit the same button again, it starts to play it again a tiny bit before it cuts the first sequence. So for a split second, there is overlapping audio.

I am attaching an updated log; I hit my lower left button, waited a couple seconds, then hit it again. This should stop playing the sample and instantly restart it from the start, but the stopping seems to have a tiny bit of delay.

I hope the above made sense. To explain it another way, if I spam pressing the sample button over and over very fast, the first split second of the sample plays over each other multiple times. log.txt

[FrostyCoolSlug]

Ok, I'll probably take a look at this one in the couple of days, My guess is that there's an audio buffer flush happening when you hit the button a second time, rather than the output being killed (just to confirm, is this definitely a new problem?).

For now, I'm going to clean up the extreme levels of logging then get some sleep :)

[hllf]

Yeah that's a new problem.

Just to let you know. The way it was prior to the last 3 days of commits, it did cut the audio before restarting, but it wasn't as smooth as it is with the native goxlr app on Windows. The one from the manufacturer I mean. Like it would cut the audio and then not restart it quite as fast it should. I'm talking a fraction of a second, but it was slower than it should be. So now it's too far the other direction where it starts to play it a second time before it kills the audio. Where we want it is in the middle where it will cut the audio and start it over with 0 delay, so it sounds seamless.

Thanks again for all your help; you have done an amazing job with this, and being able to run this on the Mac is absolutely amazing, and not only that, it's a 100-times better experience than the native app on Windows.

[FrostyCoolSlug]

Ok, just because I happened to be there, could you give the latest commit a try on that issue? I've tweaked the code so that if it's stopping a sample to play another sample it does a more agressive shutdown.

[hllf]

Sure, checking now...

[hllf]

No, still cutting the audio a split second after it starts playing it from the beginning.

[FrostyCoolSlug]

Ok, last commit for this one for today, if it still doesn't work correctly I'll look into it closer tomorrow!

Thanks for the help and checking :)

[hllf]

This changed the behavior for sure, but now it's a lot worse.

It does cut the audio before it starts playing it again, but there is a long delay after I hit the button before it stops the audio and starts it again. Not only that, but there is a bit of a delay too from when it stops playing to when it starts it again.

Definitely needs more tweaking. I think you made it way too aggressive this time. :)

[FrostyCoolSlug]

Damnit, yeah I'm seeing that here as well. I've just made one final push with hopefully a 'final' fix (straigh up dropping the audio stream when attempting to play a new sample) which may yield some results. If this doesn't work I'm going to need to look much deeper into the problem. Can you give this final one for today a try?

Thanks.

[hllf]

Okay this made it more like it was before the last change. The delay is gone, but it is back to cutting the audio a tiny bit after it starts to replay the sample. That being said, it is smoother; now if I spam the button really fast, it is a lot more smooth with absolutely no abrupt stops/starts. But since it is still starting the playback a split second before the previous stops, the very beginning plays over each other.

So it still needs work, but it's getting there! If you like, I can record a demo for you, or if you like, we can always hop on Discord or something, so I can demonstrate for you in real-time if that would help.

[FrostyCoolSlug]

Ok, from what I can tell, at this point it's CoreAudio playing back remaining samples in the playback buffer, as no new samples are being submitted after a 'Stop' message is sent. I've reduced the buffer sizes a bit which should help here, can you give that a test? (Sorry, I keep saying 'last one' but then another idea pops up!).

In addition, I'm not sure how you're building the util, but could you also try with cargo build --release and use the binaries in target/release/, it's possible the delay is being caused by slower teardowns in debug builds.

Otherwise, could you please drop a demo here of what it's sounding like, and I'll try and work out the timings.

Thanks!

[hllf]

It's absolutely no problem. I'm a software developer myself, and I know what it's like being up in the middle of the night trying to solve a problem and going, one more try, one more try. So I'm more than happy to help in any way that I can.

It's absolutely perfect now! Like I mean beautiful. It sounds seamless with 0 delay in starting the audio over, and it's stopping the playback perfectly and instantly starting playing it again.

I'll do more testing tomorrow with more samples, but I think you did it!

[FrostyCoolSlug]

Awesome, with any final testing can I ask that you double check the CPU usage of the daemon? With smaller buffers comes more iteration and potentially more CPU usage, I'm not seeing any notable impact here on Windows but just need to confirm it's fine on MacOS as well.

For now, I can finally sleep :D

[hllf]

Following up here - I have not noticed any CPU utilization issues since making the change. I think it's good to go.

[FrostyCoolSlug]

Perfect, thanks. This was released with 0.10.0 yesterday, so I'm gonna close this issue.

Thanks again!