getmusicbee.com
General => MusicBee Wishlist => Topic started by: hiccup on August 04, 2017, 09:09:35 PM
-
I recently purchased a new dac, and with MusicBee there is now the problem that a fraction of the beginning of a song is cut-off.
It's only a tiny bit, but just enough to mute the attack of the first piano/drum/guitar note.
I have tried all possible settings, and I found that it is possible to solve this issue by increasing the buffer, but that will only work when directsound is selected.
But for asio or wasapi the buffer seems to have no effect on this problem at all.
I then tried foobar2000.
The main 'Buffer length' setting there also didn't solve it.
But then under 'advanced' I found a secondary buffer setting, named something like 'hardware buffer setting for wasapi event mode' (you can also set a separate buffer for 'push' mode)
Increasing that from 25ms to 100ms immediately solved my issue.
So it looks like the existing buffer setting in MusicBee is not enough to solve some issues with asio/wasapi.
That seems to need some 'hardware' buffer setting.
So, that's my request.
edit,
I just noticed that the settings.ini has an entry for this, but changing the value there from 0 to 100 (or 1000) doesn't do anything.
So that might be a bug?
-
...there is now the problem that a fraction of the beginning of a song is cut-off.
It's only a tiny bit, but just enough to mute the attack of the first piano/drum/guitar note.
I've also noticed this in wasapi/asio, only ever occuring on the first track of a list.
I found that rapidily double-clicking the play buton (effectively pausing the track right at the begininng) and then pressing the play button eliminates this.
I'm assuming that before starting to play, MB doesn't wait the fraction of a second for the buffers to fill and so you lose that little bit of playback.
-
I've also noticed this in wasapi/asio, only ever occuring on the first track of a list.
Yes, that is the same behavior that foobar2000 has when the buffer is set too low.
The first track is cut-off, the next in a playlist will play fine.
I found an earlier post where it was stated that if in .ini the setting is '0' (=default), the buffer will actually be 83ms.
But I doubt if that's the case, since when I set the buffer to 83ms in foobar, the cutting-off is solved.
So it seems that the wasapi hardware buffer is plain defunct.
-
if you have event mode enabled, in MusicBee3Settings.ini you can set
<PlayerWasapiEventModeBuffer> to the number of milliseconds
-
if you have event mode enabled, in MusicBee3Settings.ini you can set
<PlayerWasapiEventModeBuffer> to the number of milliseconds
Yes, but as I was trying to explain, that seems defunct.
Changing the value there doesn't seem to make any difference at all.
-
I've also noticed this in wasapi/asio, only ever occuring on the first track of a list.
Yes, that is the same behavior that foobar2000 has when the buffer is set too low.
switched back to asio and increased the buffer size to 512 samples - no problems now
@ Steven
I was reading the BASS_WASAPI documentation and found this:
buffer The length of the device's buffer in seconds. This is a minimum and the driver may choose to use a larger buffer; BASS_WASAPI_GetInfo can be used to confirm what the buffer size is. For an output device, the buffer size determines the latency.
but you say
if you have event mode enabled, in MusicBee3Settings.ini you can set
<PlayerWasapiEventModeBuffer> to the number of milliseconds
Does the .ini making the adjustment back to seconds?
-
Does the .ini making the adjustment back to seconds?
Funny that you observed that too.
I also wondered why the ini entry for event buffer didn't say 'Ms', as the 'regular' buffer entry does.
So besides entering something like '100', I also tried '0.1' and 0,1'.
But as soon as MB starts, these values get reset to plain '0' again.
-
yes its converted to seconds
-
yes its converted to seconds
So that means to get 100ms, you should enter 0.1? (or 0,1)
-
you should enter 100
-
you should enter 100
Ok, so that's what I have been doing from the start.
But this doesn't have any noticeable effect, and it it doesn't solve the problem of the first tiny part of audio missing.
As stated before, in foobar2000 setting it to 100ms has an immediate effect and will solve the issue.
So there seems to be a bug with MusicBee/BASS handling the event buffer.
-
Would you prefer to let this rest until after 3.1 is final?
Or maybe you'd prefer an 'official' bug report?
-
out of curiosity does this version make any difference? (nothing to do with buffers)
http://www.mediafire.com/file/bikqpa7dap51w21/MusicBee.zip
-
nope
-
does this version make any difference:
http://www.mediafire.com/file/cc6o3yi671l4iop/MusicBeeWaspiNoRampIn.zip
-
does this version make any difference:
http://www.mediafire.com/file/cc6o3yi671l4iop/MusicBeeWaspiNoRampIn.zip
Regrettably not. And changing event buffer values still has no effect at all.
-
for v3.2 i have put in a 100ms delay for the first file played with WASAPI output
-
for v3.2 i have put in a 100ms delay for the first file played with WASAPI output
Any chance that if v3.2 is going to take a while to get it's first release, you could retro-fit v3.1 with this?
Or are you hesitant because it might screw things up for other users?
-
i can add it to v3.1 but wont be able to do it for a day or two
-
That's great. And sorry for perhaps being a bit pushy.
-
i forgot to mention, the patch earlier today included this change.
If it still doesnt work i have one last thing i can do
-
Alas, no difference. Still a cut-off at the beginning of playback.
edit,
I notice this is the same for both event and push mode.
Only directsound starts flawless.
-
i have made one last change which is available now
-
No difference at all.
A pity, and especially frustrating since with foobar I am still able to pinpoint it to exactly this:
(https://i.imgur.com/1sc0asr.png)
If set to 60, I get the same audio truncation as with MusicBee, and by setting it to 80, it is solved.
Anyway, thanks a lot for the time and effort you've put into this.
I'll just hope that perhaps some future Windows 10 native USB audio drivers, or newer drivers for my Amanero usb receiver solves it for me.
-
I made a thread on this a year ago in the wishlist forum too. I was in the exact same boat as you, I bought a hifi DAC, but the first second of every song was being cut off. I made a thread in this forum asking for an option to include second(s) silence to the start of every thread. But it was just getting ignored. No one replied to it. Eventually, I just asked Phred to delete the thread, and I stopped using Musicbee and switched to Foobar.
The reason there's a silence is because the DAC needs a second to initialize. There are players out there like Jriver that just take account for DACs automatically, and there's no silence at the start of tracks. For Foobar, there's the DSP "Affix silence". I set it up to play a 500 milliseconds silence before starting every track, and it works well.
Glad it got attention though, maybe I can go back to Musicbee. Used it for years and enjoyed it.
Also, I wanted to add, 100ms is not enough. Try 500ms. It might depend on the DAC you're using though.
Also, please add support for ASIO and/or include an option for silence at the start of tracks :)
-
Steven has put a lot of effort in this over the last period.
You might want to try the latest update, and fiddle around with the buffer settings. (also in the .ini file)
Perhaps you are able to solve it for your dac now?
It did solve similar issues for other members too.
For me it's really some 10ms that seems to be able to make the difference. (trying it in foobar2000, that is)
Having it 500ms or longer doesn't make a difference for my setup at all.
With all settings (except directsound) something like the first 50ms is truncated.
(just the very first attack of percussion, guitar string etc.)
The fact that Steven has not been able to fix this for my setup is proof to me it is really a complicated matter, and also very hardware dependent.
For example, I also tried MediaMonkey.
Whilst it has almost identical settings to foobar in regards of setting options for push and event buffers, MediaMonkey also keeps truncating the beginning of the sound no matter what I set those to.
But maybe there is some truth in your suggestion of 'adding some silence' to the beginning.
Yet, I don't have to activate something like 'add silence' in foobar?
Maybe that's something that foobar does differently (automatically?) when setting the buffer? I have no clue really.
But it does seem that only foobar (and me) seem to like my dac a lot...
-
Steven has put a lot of effort in this over the last period.
You might want to try the latest update, and fiddle around with the buffer settings. (also in the .ini file)
Perhaps you are able to solve it for your dac now?
It did solve similar issues for other members too.
For me it's really some 10ms that seems to be able to make the difference. (trying it in foobar2000, that is)
Having it 500ms or longer doesn't make a difference for my setup at all.
With all settings (except directsound) something like the first 50ms is truncated.
(just the very first attack of percussion, guitar string etc.)
The fact that Steven has not been able to fix this for my setup is proof to me it is really a complicated matter, and also very hardware dependent.
For example, I also tried MediaMonkey.
Whilst it has almost identical settings to foobar in regards of setting options for push and event buffers, MediaMonkey also keeps truncating the beginning of the sound no matter what I set those to.
Only foobar seems to like my dac a lot...
I still need to check it out.
Try out the DSP suggestion I was talking about with Foobar btw, while reverting that hardware buffer setting you used to default. If it works, you'll know that it's a software issue and not a hardware one. Players sometimes just struggle with certain dacs.
If you experience songs being cut off at the start while using a DAC, the solution is nearly always to enable a 500 ms silence at the start of every track. This way, what is being cut off is the silence it self, and not the actual music.
Also, for reference, JRiver has this option, describing what I stated above.
"Play silence at startup for hardware synchronization. Some hardware requires a lead time from when a signal is delivered to when sound is produced. This option allows outputting leading silence so no actual sound is lost in these cases. Note that this option is only in effect in two cases - at the first playback after the program starts, and between tracks with different sample rates. This silence will not be played between tracks with the same sample rate."
-
Try out the DSP suggestion I was talking about with Foobar btw, while reverting that hardware buffer setting you used to default. If it works, you'll know that it's a software issue and not a hardware one.
I just tried it, and it does indeed also solve the issue in my case.
(for me, adding 70ms already seems to be enough)
So that could perhaps be a path to a solution for MB.
Thanks for instilling some hope ;-)
PS
I would advice against removing older topics.
Even whilst what was raised then got little or no attention, or a solution, it will probably be found and read anyway, and might be useful to others to learn about.
-
You're welcome. Also, check the edit :)
-
You're welcome. Also, check the edit :)
I have.
It's still funny that for foobar only adjusting the event buffer is already enough.
But I remember suggesting earlier if perhaps foobar first starts playing silence during the time that was set for buffering, but that MB starts playing immediately anyway, whilst filling the buffer.
In my layman's mind that could explain it.
edit:
Just curious, if you disable the plugin, and set the event buffer to 500ms in foobar (advanced settings), does that solve it for you too?
-
Seems like they both enable the same outcome; small delay to stop music at the start from being cut off.
I don't use WASAPI though, mainly sticking with ASIO. I don't like having to fiddle around before I can hear sound from YouTube videos or other sources :o
-
Yes, you are right. In foobar, setting the buffer only solves it for wasapi, but activating the 'silence plugin' fixes it for both wasapi and asio.
Thanks, that's useful.
-
given its been confirmed this can be solved with a DSP, i will make a couple more attempts at this.
Its possible the bass function i am using is not doing what i think its doing, so i will make one more attempt after this if it doesnt work
https://www.mediafire.com/file/1gtbnfct3qd2f9p/MusicBee.zip
its hard-coded for 0.5 seconds. Even if it does work i wont include it in future v3.1 patch updates and will only officially include it in v3.2 via a configurable setting
-
This indeed fixes it for me. Both for wasapi event, and push mode.
(not for asio, but that's probably to be expected)
Thanks! I'll keep using this one until 3.2 gets released.
-
it should have worked for ASIO
-
it should have worked for ASIO
I double-checked, and it doesn't work on asio for me. Only for wasapi.
(which is perfectly satisfactory for me personally)
Perhaps rurutia10 has other results with it?
-
Yep, working fine for me now with both WASAPI and ASIO.
-
I now have this pre-silence tweak working with asio too.
When checking the asio output configuration settings, I noticed that by default all kind of surround channels were enabled.
(https://i.imgur.com/m585sE8.png)
I disabled all but Left and Right front, and now the audio isn't truncated for asio also anymore.
(https://i.imgur.com/QL9cXHz.png)
This might be device-specific, but I thought to share it anyway.
-
In regard to this thread, I noticed that un4seen has just released a revised basswasapi.dll (2.4.2) today, whose description says :
"Adds support for lower latency shared mode on Windows 10, more precise latency measurement, buffer size specification in samples, and notification of unexpected stoppages."
Steven, maybe this could be helpful in supplying the additional buffer settings you have been working with?
-
Well spotted.
I just tried this new dll (on a separate portable test installation), and it solves one of the problems I have been experiencing:
In wasapi mode, I couldn't skip within the playing track by using the progress- or wavebar, because then the playback would immediately freeze.
That seems to be resolved by using this new basswasapi.dll
But I am not advising anybody to do the same on their day-to-day MB installation.
I believe there is some finicky interaction between MusicBee and the basswasapi dll, so Steven probably will be needing to make some further adjustments and fine tuning of MusicBee's core to make it really solid.
But for now I am already happy that this will very likely make it possible to improve on MB's wasapi playback and buffering.
So thanks for reporting this sveakul!
-
i will include the new basswaspi going forward.
I dont see anything noted that should affect musicbee's handling nor fix any bugs but thats good news if it has fixed a mystery problem
-
Because of the buffer issue, I'll keep using the tweaked MB version you made available some five weeks ago. ( https://getmusicbee.com/forum/index.php?topic=22493.msg134648#msg134648 )
But for when 3.2 gets released, I'm keeping my fingers crossed that that will resolve both issues for me.