INTERACT FORUM
More => Old Versions => JRiver Media Center 21 for Windows => Topic started by: bjas on August 27, 2015, 01:37:51 pm
-
I am playing WAV & DSD files on MC21. No DSP other than volume leveling. Using iFi Audio Nano dac with ASIO driver. Bit streaming DSD (no DoP). At times, when I switch tracks there is a slight volume burst (less than a second) during the first one or two seconds of the new track playing. Has anyone else encountered this?
Thanks in advance for replies.
-
Some other folks have reported an issue where volume leveling seems to cut out and then fade in on track change (manifesting as a second or two of louder music on track change). I've heard it myself a few times. The devs haven't weighed in yet, but a few people have definitely reported it.
-
That happened with 21.0.2, I don't yet know whether it still happens with .3 (though I haven't seen it listed as fixed). I'll report back if it persists.
-
I've heard it but it's so infrequent it must be just the right combination of things and/or a complex timing with maybe a system process or some other odd thing
-
The problem persists into 21.0.3, unfortunately.
I've heard it but it's so infrequent it must be just the right combination of things and/or a complex timing with maybe a system process or some other odd thing
Maybe so, I don't know. In fact, that infrequency is the reason why I didn't report this immediately; I wanted to make sure it's actually happening as opposed to placebo (new software, what are the differences?) and an overly active imagination on my part.
Back when I posted the problem, I offered to investigate further, but only if someone was actually interested (as opposed to, say, a case of "Oh, that's probably related to this code change, somehow!", you know...), but no-one reacted. Also, aside from this thread, I know of two other posters who encountered the same issue, so tracking it down may be possible.
Alas, when I wrote that post, I was tired and forgot to mention all kinds of interesting details, but because no-one asked for further investigations, I thought it would be fine to leave it be.
For the record, here my original post:
It appears that sometimes, when switching tracks, Volume Leveling now "hangs" sometimes:
When switching tracks, a small part at the beginning of the next track is being played at a louder volume, then very soon the playback volume "normalizes" again. I cannot reliably reproduce this, but when I wait long enough, I will notice it on some switches. It sounds like Volume Leveling is simply disengaged during the track switch, and the re-engaged. This fits with my observation that a small amount of time will pass between ticking Volume Leveling in the DSP Studio and the volume adjusting.
The setup where I noticed this is HDMI audio out (wasapi) at 2.0, 44.1->48 kHz, -10 dB Internal Volume, and Volume Leveling.
I can confirm that this is new in MC 21. I am willing to test some more, if required, and split this into a thread of its own, but someone will need to tell me to. For today, though, I'll go to bed now.
Here the first other report:
Same for me here but with the standard analog output trough my Realtek High Definition Audio (Direct Sound). No problem in MC 20 with same settings.
Sometime a very short part (500 ms) in the beginning of the next track is played like 12 db louder, then comes back to normal.
This can be a bit dangerous with headphones :o
And here the second one:
This happens to me too....
Here additional information:
- This is on a laptop running Windows 8.1 x64.
- The AV is stock Windows Defender. I don't see how this could be an AV issue, but who knows...
- I have also encountered the issue when playing a single track on repeat. Both when the playlist contains several tracks and the repeat setting is set to single-track repeat and when the playlist only contains that single track. Therefore it's possibly unrelated to a track-change related changes in Volume Normalization levels.
- I only encountered this problem when playing audio files.
- I don't watch videos very often, and certainly not on auto-repeat in the background. This means it may well happen with video playback also, and I just didn't encounter it yet.
- Both ASIO and WASAPI output are affected. Here the settings (mostly DSP):
- ASIO (to a peachtree X1 (http://www.peachtreeaudio.com/x1-usb-spdif-converter.html))
- ASIO Driver
- Device: Channel offset 0, no channel swap
- Volume: Automatically try to choose at playback time
- Buffering: 50 ms (Use large hardware buffers: yes)
- Output
- Device uses only most significant 24-bits: yes
- DSD bitstream in DoP format: no
- Internal Volume: -10 dB (80%)
- Loudness (Volume Reference Level: 100)
- Output Format
- Output Encoding: None
- Channels: 2 (stereo)
- JRSS Mixing
- Detect stereo sources in surround: yes
- Sample rate: everything to 48 kHz
- Volume Leveling
- Headphones: Standard
- Parametric Equalizer 2: Bitdepth Simulator (16bit) with Dither
- WASAPI (to a TV via HDMI output of an AMD Radeon HD 6970M, using AMD Catalyst 15.7.1 drivers)
- WASAPI
- Open device for exclusive access
- Maximize device volume during playback
- Bitdepth: Automatic
- Buffering: 100 ms
- Internal Volume: -10 dB (80%)
- Output Format
- Output Encoding: None
- Channels: 2 (stereo)
- JRSS Mixing
- Detect stereo sources in surround: yes
- Sample rate: everything to 48 kHz
- Volume Leveling
- Lately, I have been thinking that at least the amount of time for which the unleveled audio is played may be related to the buffer size in milliseconds. That is because, subjectively, ASIO has shorter bursts of unleveled audio. I have not yet bothered to verify this.
- When playing non-sequential tracks, I have set MC to do an aggressive cross-fade (1s). In such cases, the burst happens sometime during the fade and ends before the fade is complete.
- I don't know / didn't pay special attention whether the burst starts at the time at which the cross-fade starts or sometime later.
- I also didn't pay special attention to whether only the "fade-in track" or the "fade result" is affected by the burst.
Wow, that is longer than I initially thought it would turn out to be... :o
-
Happens frequently, but not always, 21.0.2. And I have only tried it on a client. So far, only tested with volume levelling and headphones dsp on. Never heard it in mc20.
A couple of seconds after track change, a sudden volume burst lasting, I'd say, a second or less. Never more than once for each track.
EDIT: Using a Hegel Superdac via usb, WASAPI event style enabled (diabling had no effect), 100ms buffer (changing buffer size did not help).
-
Have also heard this infrequently. Fortunately never while wearing headphones. Something definitely funky... will try and capture a log when it happens.
-
For me it happens frequently, but not always. I did not experience it with MC20. Thanks for all of the replies. It's nice to not feel alone. :)
-
Sounds odd, from the top of my head I have no idea where this might be coming from. Only volume leveling change was pretty straight forward.
But I'll test, and we'll find it. Although I'll be on vacation next week, so might take a bit more time than usual.
-
Have also heard this infrequently. Fortunately never while wearing headphones. Something definitely funky... will try and capture a log when it happens.
Thanks for that post. I didn't look for a functionality to capture logs, but now that I looked, I found one. I'll try to capture a log, too.
<rant>I even had it captured this morning, but then I found out that the logging becomes active only once you actually close the logging window. Since I obviously have no idea how to log properly and concisely, my log may end up large.</rant>
-
If I did it right, I just captured a Burst in a log. If I didn't do it right, please direct me to instructions on how to do it right.
Occasionally, I would open the logging settings and reset the log, if no Burst happened. I hope that this is fine.
I used a 14 seconds long audio track on repeat to draw out the issue.
Once the Burst happened, I terminated logging rather quickly, so it should be toward the end.
-
I think this should be fixed next build. Thanks to Brad for his nice job debugging!
-
Thank you! You and John did most of the work, but it was nice to have a bug that I could reproduce.
-
Cool, thank you!
Edit: May I know what the problem was, roughly speaking?