All times are UTC+01:00




Post new topic  Reply to topic  [ 707 posts ]  Go to page Previous 1 2 3 4 571 Next
Author Message
PostPosted: Sun Nov 20, 2022 10:36 pm 

Joined: Wed Jun 03, 2015 7:03 pm
Posts: 198
Quote:
Quote:
Quote:

The old GUI does not scale at all, which means that it's getting nearly impossible to add new settings to it. Just look at how the multiband compressor has 9 pages or so with settings. If you have issues with the new GUI, please report them, and we'll try to do something with what you're reporting.
Add even MORE settings? How about fix current settings/filters?

- Input2 practicaly useless as backup input. Should be literally removed. Also VLC that should be nice to have, but it's not working and also not planned.
- ND, never got dynamic detection on input.
- FM calibration still has bugged band-narrowed EQ and still not replaced by proper PEQ.
- New AGC bugged and wrongly builded especially window function.
- ITU filters mostly wrong and not even same one in AGC and MB.
- MB flat bands are bugged, do not use that!
- MB's output is wrong and not always same as 'hear' (limiters), output per band is fine tho.
- Still no proper crossover settings for every number of bands. Long time ago that should be altogether set and removed.
- Main clipper
- etc etc

But i guess some of those, or all of them, are not important, right, Like Final Limiter, not important to be in audio processor, literally i begged 2 years for fix, like now i'm asking for additional button in hard limit to be able to fully bypass FM, pre-limiter improvements, gate freeze detection after AGC option, possibility to use only gate freeze and not with gate slowdown. etc.. most of them are really simple stuff.
How about removing and simplifying some things, instead just adding new? We still have old and new (and sometimes old-old..), compressors, bass filters, and many more. For compatibility with presets? What presets? In best case half of them are anyway bugged, or bad.
And finally, new gui might be way better if at some point things got simplified and useless stuff removed. And naah, 'basic' modes are not that!
It's pointless to ask someone what's wrong with newgui, many things are. It firstly need to be simplyfied, people don't know to even use old one wich is still way faster for navigation, you cannot justify that i see RF spectrum analyzer, even if i dont use it and don't care about it, and in same time i don't see how my AGC is doing. Also those drop down/minimized menus, why th are they minimized when there IS reserved space for it vs current windows size.

I promised on many places, long time ago, that i will setup their input2 for backup, they all knew about that feature, now i am asking You all this and i need answer only about input2, will old gui have new I/O engine at all and/or any time soon?
I agree with Bojcha.
I agree with both, too.

_________________
https://fmfeeling.com


Top
   
PostPosted: Mon Nov 21, 2022 9:09 pm 
User avatar

Joined: Tue Mar 17, 2009 2:56 pm
Posts: 4151
Quote:
Quote:
All seems to be working fine.
For some reason buffer constantly shows it's under 50% with fully synced buffer. Then i checked in new gui and it's same but..
https://i.imgur.com/kIbQ13F.png
Main buffer bar is around 40% (same as in old gui) but in sync window is fine at 50% (new gui).
Also slightly different syncing when using different "Audio quality" values but still works fine. Also slightly different syncing when using "Don't process highs" but again all is working fine.

Since recently i always use "Don't process highs" with Audio quality 130+%, becasue it's removes artifacts caused by LPF. it also improves LPF efficiency greatly, and that's with HPF with no more then 18200 to keep cpu usage lower. So tripple win there.
Please keep an eye on whether it doesn't cause any sync issues. If not, it should be ok. I just tested it here, and indeed the main GUI shows the minimum buffer filling, the sync window shows the buffer filling at a specific point in time, which is typically fuller than the - random - moment in time when the GUI gets updated.

Edit: I'll check tomorrow if I need to make it aim for 1 step higher in buffer filling. (1 step -> The audio is sent to the output sound card in blocks of a certain size; if I make the buffer filling 1 such chunk bigger it will on average be in the center. But I want to compare the actual audio delay between the old and new code first, since the measurement has changed so it could be that the behavior is actually the same as before, just the GUI isn't).

Edit: Buffer values around 0 ms always fail in the new code, and they didn't in the old code - I'll add an offset of 1 chunk to the buffer size to fix that. The displayed size will still be slightly below the center.

Edit: Solved, I think. 2 changes:
- Minimum buffer size is 1 sound card chunk larger, we've added one. This is for non-ASIO only. Its behavior is closer to that of the old GUI framework, and typically works at buffer size 0 if the CPU load is very low.
- Sync now acts as if the buffer is 1 sound card chunk less full. With that, it aims at the center instead of at 1 chunk below the center, just like before.
I can't go lower then ~45ms buffer size, everything under that starts with can't-sync correctly and then audio drops.

_________________
control point
control point2


Top
   
PostPosted: Mon Nov 21, 2022 10:15 pm 

Joined: Wed Dec 04, 2019 6:12 am
Posts: 28
Quote:
RDS: Restored old RadioText A/B behavior non non-UECP inputs to how it worked before version 9.92/10.00; new behavior was causing issues.
Is there any chance to create a button for this, and let the user decide how this works?


Top
   
PostPosted: Mon Nov 21, 2022 10:22 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Quote:
Quote:
RDS: Restored old RadioText A/B behavior non non-UECP inputs to how it worked before version 9.92/10.00; new behavior was causing issues.
Is there any chance to create a button for this, and let the user decide how this works?
Is the new behavior better for you? I was thinking of making it configurable but I'm not sure if it has any benefits.


Top
   
PostPosted: Mon Nov 21, 2022 10:38 pm 

Joined: Wed Dec 04, 2019 6:12 am
Posts: 28
I just found on a Sony desktop tuner with the A/B flag method, when the flag changed, it shows the new RT, and the next turn the old RT message once, for the last time, and the new RT again. Without changing the flag I can't experience this behavior.

Not a big deal, but if this is not too difficult to develop, probably worth it.


Top
   
PostPosted: Mon Nov 21, 2022 11:47 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Quote:
I just found on a Sony desktop tuner with the A/B flag method, when the flag changed, it shows the new RT, and the next turn the old RT message once, for the last time, and the new RT again. Without changing the flag I can't experience this behavior.

Not a big deal, but if this is not too difficult to develop, probably worth it.
That sounds like a bug in that decoder - what you're describing doesn't make sense if you read the spec. According to the spec, changing the A/B flag means that the buffer needs to be cleared, and that's all. It will mainly affect the RT+ behavior, and potentially without clearing it, it might show a mix of the old and new text with bad reception.
Quote:
An important feature of type 2 groups is the Text A/B flag contained in the second block. Two cases occur:
- If the receiver detects a change in the flag (from binary "0" to binary "1" or vice-versa), then the whole RadioText
display should be cleared and the newly received RadioText message segments should be written into the display.
- If the receiver detects no change in the flag, then the received text segments or characters should be written into
the existing displayed message and those segments or characters for which no update is received should be left
unchanged.
This does not sound at all like what you're describing...


Top
   
PostPosted: Tue Nov 22, 2022 2:28 am 
User avatar

Joined: Tue Mar 17, 2009 2:56 pm
Posts: 4151
Beta005 much better, Sync is kinda nicer, buffer bar is much more steady at low buffer sizes and sync still fully functional at ~25ms, in beta004 was ~43ms.

How much ms is that one chunk (block) at 48kHz?

_________________
control point
control point2


Top
   
PostPosted: Fri Nov 25, 2022 11:49 am 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Quote:
Beta005 much better, Sync is kinda nicer, buffer bar is much more steady at low buffer sizes and sync still fully functional at ~25ms, in beta004 was ~43ms.

How much ms is that one chunk (block) at 48kHz?
It's typically 1024 samples, so 21 ms. Oddly, the old I/O framework often gave bigger latencies than the new one though, at the same setting. It depends on the sound card protocol used, I measure about 80 ms more at the same settings before this change if I test it with MME sound cards. Which must indicate some bug in the old framework. That's why we've waited so long to integrate this; it's risky because it could (and clearly does) change the behavior. So I'm combining it with version 10, which is a big change anyway, where we can have some (small) compatibility breaking changes.


Top
   
PostPosted: Fri Nov 25, 2022 11:55 am 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
BETA006 is posted! There's a big change in the Winamp plugin (the VST will be next).

The Winamp plugin can now run in 2 modes:
  • The normal mode where it receives input from the plugin and sends output to the plugin - if necessary it can also send FM output directly to a sound card.
  • The new mode which routes everything through the new I/O layer. Basically, the I/O layer treats the plugin input and output as sound cards, and can combine them with for example an extra input for The BIMP. So you can now run Stereo Tool inside any playout software, and have it ingest an extra microphone input for example, so you can directly talk through the music. A simple mixing console is included in The BIMP so you can use that to control which microphone is open when.
The new mode is mainly intended for use with The BIMP, but it can solve several other issues as well. For example, in some playout software Stereo Tool can cause hiccups because Stereo Tool processes audio in blocks of (by default) 2048 samples, and it blocks during processing. Using the new I/O layer, there's an internal buffer and no blocking anymore. Also, you can now send FM output to a different sound card and enable synchronization to the input without loosing the output that goes back to the playout system, because due to the internal buffer we can resample the output to match what the host expects.


Top
   
PostPosted: Fri Nov 25, 2022 5:04 pm 
User avatar

Joined: Tue Mar 17, 2009 2:56 pm
Posts: 4151
wasapi not good.

_________________
control point
control point2


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 707 posts ]  Go to page Previous 1 2 3 4 571 Next

All times are UTC+01: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