Bugzilla – Bug 4580
Brief burst of high volume noise when switching digital inputs
Last modified: 2008-08-04 14:02:53 UTC
NB: Before reporting this, I updated to the latest nightly (6.5.1-10915, 9th Dec 2006) and Transporter firmware (version 24) to check that the problem is still present, and it is. Symptom: when switching to the RCA COAX digital input, and when there is something playing on the device connected to that input, there is a brief burst (less than half a second) of noise at high volume, regardless of where the Transporter's volume control is set. I think it is probably a tiny snatch of whatever music is playing on the connected device, but at full volume. I have not been able to test the other digital inputs, so cannot say if the same will happen on them. Other observations: 1. Switching back to streaming from Slimserver while the connected SPDIF device continues to play does not cause the same burst of high volume noise. 2. If the connected device is not actually playing anything, there is just a quiet "tick" as the input is selected (so no problem there). Workaround for now is easy: make sure the connected device isn't playing when switching inputs. Nevertheless, I thought it was worth reporting. Far be it for me to suggest possible solutions, but perhaps the firmware could mute the output briefly while it performs the input switching?
Ross, could you have a look at this one? If you need spdif or toslink cables I have some
I wasn't able to reproduce this, but maybe Clive has something else he'd like me to try? Here's what I did, I used a SB3 as my source. SB3 via digital coax -> Transporter digital input. I connected the Transporter to some computer speakers with a RCA to headphone jack adapter (thanks Chris!). I was able to pass through no problem, I switched between various unused inputs and the digital coax 20 times in various ways and I was never able to hear any burst of high volume. I didn't hear any click, pop, snap... nothing but what I expected. Am I missing something in the equation here Clive? Do I need to have two sources to switch between?
Ross, the burst of noise only happens if the device feeding the RCA COAX input is playing something. Also, if you had the Transporter's volume set to max, using the external computer speakers for volume control, then you wouldn't hear the issue. You need to set up like this: 1. Turn the Transporter volume turned down quite a long way (eg. to -35dB). 2. Start playing something on the device that is attached to the RCA COAX input, and make sure the volume level of its digital output (if it has one) is set to maximum. 3. Now switch the Transporter to the RCA COAX input. You should hear a brief burst at high volume before the music from the external device starts playing at the expected low volume. I can also report that the Toslink input displays the same burst of noise (my PVR is connected to that). I see that someone else (forum member "dlite") has noted the same issue, so I don't think it's peculiar to my two devices (a Cambridge Audio DVD player and a Topfield PVR).
No trouble hearing it now! Thanks for clarifying Clive. Steps to reproduce are clear. 1. Set Transporter to -35db or similar. 2. Switch to a digital input source that is currently playing A loud pop is obvious everytime.
Changed the severity and milestone.
This bug is fixed in the upcoming Transporter firmware 33. It needs to be tested internally first. You will be notified again when it is made part of a release.
It is now included as of change 14252, Nov 1 builds onward. marking as fixed, please update/test/verify and reopen if there are any issues.
I have tested this with the 1st November nightly build of SqueezeCenter 7.0 - Transporter firmware 33, and the problem is fixed (for me). The burst of noise is absent when changing digital inputs using either the Digital Inputs plugin, or if you do it via the "setup" top-level menu. There is sometimes a tiny "tick" as you change inputs, but it is not a problem. (I suspect it may be due to the amplitude suddenly dropping to zero for a moment). Many thanks for sorting this out.
080319-003325 support has another customer seeing this issue with firmware 36.
Hey. As have others, when I try to use the digital inputs, a very loud burst of volume comes through my speakers. I had been told that firmware 33 solved the problem, but when I recently upgraded to 36, the problem continued. From the forum, I know that others are having the same issue post-fw33. Some say fw40 has solved the problem, but as you know, 40 is only in beta. Many on the fourm have had problems with the beta. I emailed customer service last week about this issue. Yesterday, Julius sent me to you. Help please. The digital inputs are one significant reason I bought this very expensive product. Thankyou.
Hey. I was just wondering whether any progress had been made on this? Please let me know. Thanks.
You will need to upgrade to FW40 to get this fix. It can not be ported back to older versions, as the fix was the result of fundamental architectural changes.
(In reply to comment #12) > You will need to upgrade to FW40 to get this fix. It can not be ported back to > older versions, as the fix was the result of fundamental architectural changes. OK. Thanks. How do I do that on a Thecus NAS? Currently, there is a module to install 7.0 w/fw36 on the Thecus, but no module for (beta) 7.01 w/fw 40. Is there a way to just install the fw? Please let me know. Thanks.
Fixed in FW42, will be released in SC 7.1
I'm confused. This bug was definitely fixed in FW33, and remained fixed in FW34 and FW36. Now I see a comment that it's fixed in FW42. Did the bug reappear in FW40? (I haven't yet tried anything later than FW36).
Clive, yes I believe that's the case - there was a regression at V.40. Not too surprising actually, because a large portion of the firmware related to audio I/O was rearchitected at that point.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.