All times are UTC+02:00




Post new topic  Reply to topic  [ 94 posts ]  Go to page Previous 13 4 5 6 710 Next
Author Message
 Post subject: Re: Stereo Tool 9.70
PostPosted: Wed May 12, 2021 9:20 pm 

Joined: Wed Nov 08, 2017 3:16 pm
Posts: 98
Quote:
Quote:
Sorry for the hold up, but now I can say with confidence that 9.70 beta 1 has fixed my I/O problem.

Thank you, Hans.
Ok. In that case, I have a suspicion that there might be some settings that I can change to fix the PortAudio issue, instead of having to go back to the old version. Apparently the changes that I made in 9.70, which I reverted here, caused at least some of the problems. Some of the settings were set to "undefined" ("let PortAudio figure out what's right") only in 9.70 - but some have *always* been set to that. So, for the next build I'm going to make some changes where I take full control of what happens from Stereo Tool.
i believe that should solve my current work-arounds.


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Fri May 14, 2021 2:12 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 10245
Some more progress. Yes, there are bugs in PortAudio (and not just in the new version, in the old one as well - although they might be different).

Input block sizes for some devices
For certain devices, for Wasapi and Kernel Streaming INPUTS, only VERY specific buffer sizes give good results. For example, on my webcam microphone running at 32 kHz in both KS and Wasapi, I only get good audio if the input buffer is a multiple of 320 samples. Any other value inserts blocks of zeroes in the input (in a slightly different way for Wasapi than for KS). For Wasapi, PortAudio actually suggest a latency of 320 samples (as the maximum - if I use the minimum suggested value, which is lower, it fails). But Kernel Streaming for the same device suggests 2730 samples, which obviously isn't even close to being a multiple of 320.

The problem that I have now is that I have no way of knowing if there's a single value that works for all Wasapi/KS devices. If that's the case, the solution is easy: Just hard-code that value. I think I'll have to make a version with configurable buffer sizes and then get feedback from people here.

Exclusive mode
I can make one small improvement: For Wasapi, this ONLY happens when I open it in Exclusive mode, in non-exclusive mode all buffer sizes work. The old code tried to open in Exclusive mode first, and fell back to non-exclusive if it failed. I'm inverting that behavior, so as long as the Wasapi sample rate is set correctly in Windows, it will now automatically open it in non-exclusive mode.

Outputs
For the outputs, it doesn't really seem to matter much what the settings are, I've hard coded it to use blocks of 4096 samples (at 44.1/48 kHz, 16384 samples at 192 kHz) for now, which seems to be very stable. I might make it configurable later.

Having said this, there's of course always a possibility that there are output devices that are as sensitive to block sizes as my microphone is.


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Sat May 15, 2021 12:17 am 

Joined: Wed Nov 08, 2017 3:16 pm
Posts: 98
Quote:
Some more progress. Yes, there are bugs in PortAudio (and not just in the new version, in the old one as well - although they might be different).

Input block sizes for some devices
For certain devices, for Wasapi and Kernel Streaming INPUTS, only VERY specific buffer sizes give good results. For example, on my webcam microphone running at 32 kHz in both KS and Wasapi, I only get good audio if the input buffer is a multiple of 320 samples. Any other value inserts blocks of zeroes in the input (in a slightly different way for Wasapi than for KS). For Wasapi, PortAudio actually suggest a latency of 320 samples (as the maximum - if I use the minimum suggested value, which is lower, it fails). But Kernel Streaming for the same device suggests 2730 samples, which obviously isn't even close to being a multiple of 320.

The problem that I have now is that I have no way of knowing if there's a single value that works for all Wasapi/KS devices. If that's the case, the solution is easy: Just hard-code that value. I think I'll have to make a version with configurable buffer sizes and then get feedback from people here.

Exclusive mode
I can make one small improvement: For Wasapi, this ONLY happens when I open it in Exclusive mode, in non-exclusive mode all buffer sizes work. The old code tried to open in Exclusive mode first, and fell back to non-exclusive if it failed. I'm inverting that behavior, so as long as the Wasapi sample rate is set correctly in Windows, it will now automatically open it in non-exclusive mode.

Outputs
For the outputs, it doesn't really seem to matter much what the settings are, I've hard coded it to use blocks of 4096 samples (at 44.1/48 kHz, 16384 samples at 192 kHz) for now, which seems to be very stable. I might make it configurable later.

Having said this, there's of course always a possibility that there are output devices that are as sensitive to block sizes as my microphone is.
i actually like the idea of having a configurable block size for input.
being able to match the block size of the output device feeding the input of ST is a great idea.
this should greatly improve timing and stability.


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Sat May 15, 2021 12:35 am 
User avatar

Joined: Tue Mar 17, 2009 2:56 pm
Posts: 3722
Quote:
i actually like the idea of having a configurable block size for input.
being able to match the block size of the output device feeding the input of ST is a great idea.
this should greatly improve timing and stability.
True, with Jitter readings, even better.

_________________
control point


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Sat May 15, 2021 1:37 am 

Joined: Sat Nov 10, 2012 2:16 am
Posts: 97
Location: Australia
Quote:
Ok, let's try this:

https://www.stereotool.com/download/ste ... 71-001.exe - 32 bit stand alone, new PortAudio, old timings
https://www.stereotool.com/download/ste ... 71-001.exe - 64 bit stand alone, new PortAudio, old timings
Hi Hans

Has there been any alterations to the uMPX code in this ST release?

Seeing errors pop up in the uMPX Decoder task from the 64bit v9.70-Beta001 like -:

2021-05-15 08:26:48.747 trace: After recovery: Row 2 of recovery packets is missing
2021-05-15 08:26:48.747 trace: After recovery: Row 3 of recovery packets is missing
2021-05-15 08:26:48.747 trace: After recovery: Row 4 of recovery packets is missing
2021-05-15 08:26:48.747 trace: After recovery: Row 5 of recovery packets is missing
2021-05-15 08:26:48.747 trace: After recovery: Row 6 of recovery packets is missing
2021-05-15 08:26:48.747 trace: After recovery: Row 7 of recovery packets is missing
2021-05-15 08:26:48.784 --------End trace:
2021-05-15 08:26:48.881 error: Packet received is from a newer version of MicroMPX! Packet version is 5. Cannot decode. (Recovered: false)
2021-05-15 08:26:48.884 --------Trace:
2021-05-15 08:26:48.747 trace: After recovery: Row 0 of normal packets is missing
2021-05-15 08:26:48.747 trace: After recovery: Row 1 of normal packets is version 3
2021-05-15 08:26:48.747 trace: After recovery: Row 2 of normal packets is version 3
2021-05-15 08:26:48.747 trace: After recovery: Row 3 of normal packets is version 3
2021-05-15 08:26:48.747 trace: After recovery: Row 4 of normal packets is version 3
2021-05-15 08:26:48.747 trace: After recovery: Row 5 of normal packets is version 3

I am actually sending the decoder a v4 stream @ 768k. Audio quality appears to be fine.
Version being used is the production release of ARM LINUX 32 BIT from the website that is running under your HiBerry image (with applicable kernel updates).

Regards

Ross


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Sat May 15, 2021 1:44 am 

Joined: Wed Nov 20, 2013 6:42 pm
Posts: 53
My understanding is that beta 1 was just for testing timing issues. I found it buggy otherwise.


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Sun May 16, 2021 11:45 am 

Joined: Sat May 19, 2018 3:14 pm
Posts: 10
Hi,

Scheduling via file polling seems broke, can anyone confirm this?


Kind regards,

Arkadas

PS: after some tinkering on en off button suddenly it works?


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Mon May 17, 2021 3:08 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 10245
Please ignore any errors in that last beta, some things were severely broken. I hope that they are fixed now (not 100% sure). I have added block size settings for the main input and FM/Normal outputs for testing, which will make testing possible - I'll write some more about what I'm interested in when I post it. I'm planning to run a new beta build tonight.

MicroMPX is definitely broken in this last build, I had added some test code. I'll turn that off for tonight's build.


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Mon May 17, 2021 11:04 pm 

Joined: Wed Nov 08, 2017 3:16 pm
Posts: 98
Quote:
I have added block size settings for the main input and FM/Normal outputs for testing, which will make testing possible - I'll write some more about what I'm interested in when I post it. I'm planning to run a new beta build tonight.
im anxiously awaiting this build.
block-size has always been something i wished for but i did not bother to request, since i assumed its something most people care less about and would never be added into any build.


Top
   
 Post subject: Re: Stereo Tool 9.70
PostPosted: Tue May 18, 2021 11:12 am 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 10245
For feedback only

https://www.stereotool.com/download/ste ... 71-002.exe - 32 bit stand alone, new PortAudio, configurable block sizes
https://www.stereotool.com/download/ste ... 71-002.exe - 64 bit stand alone, new PortAudio, configurable block sizes

For the main input, Normal output and FM Output, I have added a setting to overrule the standard (suggested by PortAudio) block sizes. You can change them in multiples of 16. Note that the block sizes are calculated based on 44.1/48 kHz sample rate, so if you're running at 192 kHz for example (eg. FM output), they are internally multiplied by 4.

For most devices, it looks like it doesn't matter which block size you choose - they all work, and they only (slightly) affect latency.

However, there are some devices that only work properly at very specific block sizes. My webcam microphone input for example only sounds good if it's running at a multiple of 320 samples. ANY other number causes glitches in both Wasapi and Kernel Streaming (PortAudio suggests 320 samples for Wasapi, so the default behavior was ok for Wasapi, but not for KS, where it suggested the very weird number of 2730 samples.)

So, so far I have seen devices that work well with any number, and some that require a multiple of 320. What I want to know now is if there are other devices that require a specific value.

So, I want to ask you to enable the new "Override block size" setting (for both input and outputs, not all at the same time) and try for which values your sound cards work, and report back (also if it doesn't matter and any value works). I hope that this will result in a limited number of values that we need to support - the current slider is very hard to use for cards where 95% of the possible values don't work.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 94 posts ]  Go to page Previous 13 4 5 6 710 Next

All times are UTC+02:00


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited