Hmmm, I've actually repro'ed the issue on 2 different machines running 2 different OSes. I kinda doubt the issue is not on the Bifrost's side. But you are right that their tech support is excellent and I am sure they are working hard to identify the issue, no doubt about that. I guess I'm just a little irritated to read those messages deeming the issue as "minor" because it's not, at least for me.
But you're right, a fix down the line may be coming, I'll just wait and see how it goes.
I'm with you on this one. Schiit took my Bifrost back, sent it back to me, and when I encountered the issue again, told me that there is nothing more they can do now. I am not very pleased with this either.
Granted, Schiit did offer to refund me for my upgrade (only after I asked about it) and downgrade my Bifrost back to an Uber. I guess that's as much as they can do (other than offering me a replacement Bifrost, which they did not).
I'm just surprised at this hands-off attitude I felt like I was getting from customer service, and how this is being made out to be a "minor problem". This definitely isn't for me.
I'm just surprised at this hands-off attitude I felt like I was getting from customer service, and how this is being made out to be a "minor problem". This definitely isn't for me.
Sorry to hear your issue is not fixed, this a difficult situation at Schiit and with affected customers. Schiits are not able to get MB to manifest this issue even off customer returned units
so we will have to wait to see if they figure out what the issues are. may be you could ask schiits to send a different unit out to you for testing to see if a different unit has the same issue
I'm just surprised at this hands-off attitude I felt like I was getting from customer service, and how this is being made out to be a "minor problem". This definitely isn't for me.
Schiit has been very clear that they don't know what's causing this problem. It's not "hands-off," it's just that there's some subtle interaction they haven't been able to replicate reliably. Race conditions in digital hardware/software are hell to pin down, and this one smells a lot like one. BTW, has anyone tested whether gapless vs gappy play makes a difference to this bug?
The fact that this isn't some anomaly means there's a hardware issue and if burning these suckers in for a certain time is the fix then that's what should be done at the assembly line. AUDIO-GD does this for all their units for burn-in and failure checks to the majority of their units, the cheaper units get 100hrs while the more pricey $500+ items gets 200hrs.
A buzzing problem isn't some cute characteristic of a DAC whether or not you know how this is occurring with components and realizing that a cycle will fix things. Imagine getting a tablet or computer that needs to be reset every time you turn the Wi-Fi on and off, this is on the same level as an issue.
As my first experience with Schiit DACs I'm not top impress but their service team gives hopes. If only they didn't prematurely released the units and worked all the bugs out first.
Schiit has been very clear that they don't know what's causing this problem. It's not "hands-off," it's just that there's some subtle interaction they haven't been able to replicate reliably. Race conditions in digital hardware/software are hell to pin down, and this one smells a lot like one. BTW, has anyone tested whether gapless vs gappy play makes a difference to this bug?
By "hands-off" I was referring to how I feel that they have not been proactive with offering me a satisfactory solution. (I was first that "there is nothing we can do about it", then had to press further before they offered me a refund). I'm left in a position now where both my options are not satisfactory: 1) live with a buggy DAC and wait for a solution that might never come, or 2) be stuck with an outdated version of a " futureproof" DAC.
Anyway, I don't want to turn this thread into a rant-fest. I have chosen to wait it out and see if this problem persists and/or if a solution is found. I will contact Schiit support again if I change my mind. Just letting other people know about my experience so far so they can make informed decisions about this product.
The fact that this isn't some anomaly means there's a hardware issue and if burning these suckers in for a certain time is the fix then that's what should be done at the assembly line. AUDIO-GD does this for all their units for burn-in and failure checks to the majority of their units, the cheaper units get 100hrs while the more pricey $500+ items gets 200hrs.
A buzzing problem isn't some cute characteristic of a DAC whether or not you know how this is occurring with components and realizing that a cycle will fix things. Imagine getting a tablet or computer that needs to be reset every time you turn the Wi-Fi on and off, this is on the same level as an issue.
As my first experience with Schiit DACs I'm not top impress but their service team gives hopes. If only they didn't prematurely released the units and worked all the bugs out first.
The units were not prematurely released for the vast majority of users who have had no problems, or minor problems, with them. If this is a race condition involving the timing of events between the USB source and the Bimby, as I suspect, it can be hugely dependent on the particular source/cable combination, and pretty much impossible to replicate in the lab. Until Schiit can replicate this reliably, they won't be able to find, let alone fix, the bug. I follow/have followed plenty of bug discussions for consumer products, including vendor-internal discussions, and I can tell you that issues like this come up for a small fraction of every consumer product. It's just that most of us are in the majority of unaffected users most of the time. That's the nature of software/hardware combo bugs today, and I don't know any practice that will solve the problem any time soon.
That's unfortunately because Schiit hasn't been able to replicate the problem reliably. I'm not surprised, race conditions in hardware/software combos are notoriously hard to track down, especially since they depend on the specifics of the hardware and software outside the system under investigation. In my case, I experienced the problem once from USB just after I got the upgraded unit, "fixed" it by power-cycling, and it went away. Later, I changed my sourced to S/PDIF for other reasons, and I've not experienced the issue ever again. My spidey sense tells me that maybe the USB receiver in its interaction with the rate-switching circuitry/relays has a latent bug that only emerges for some particular timing from the USB source. Lest you think I'm speaking through my hat, I've experienced a pretty similar problem in some earlier versions of Naim firmware with gapless play, so these things happen too with top-brand multi-$K gear. As I said elsewhere, the harsh truth is that all software (/firmware/hardware) sucks more or less because we humans have very poor tools to deal with its complexity.
The fact that this isn't some anomaly means there's a hardware issue and if burning these suckers in for a certain time is the fix then that's what should be done at the assembly line. AUDIO-GD does this for all their units for burn-in and failure checks to the majority of their units, the cheaper units get 100hrs while the more pricey $500+ items gets 200hrs.
A buzzing problem isn't some cute characteristic of a DAC whether or not you know how this is occurring with components and realizing that a cycle will fix things. Imagine getting a tablet or computer that needs to be reset every time you turn the Wi-Fi on and off, this is on the same level as an issue.
As my first experience with Schiit DACs I'm not top impress but their service team gives hopes. If only they didn't prematurely released the units and worked all the bugs out first.
Previously banned under user names cablesnakeoil, placebofile and Bolos.
Joined
Dec 25, 2015
Posts
10
Likes
15
Originally Posted by earnmyturns /img/forum/go_quote.gif
What information? The delta-sigma vs multibit discussion has been had at length here and elsewhere, including Schiit's site. You can either believe those arguments, on hear for yourself. If you can't get the gear to hear for yourself, though, but there's nothing anyone can do with words to add to what has already been discussed. The OP wanted some magical "objective" assurances, which are just not available from anyone you'd want to trust, simply because the interactions between signal processing, downstream gear, and human hearing are too complex to quantify at the level of detail that matters to distinguish DACs at this quality level. You just have to hear and decide.
Information as in info on the rate switching bug. I'm talking about being objective about the bug and admitting it is a rather serious one, especially for a DAC selling in the neighborhood of 600, and the fact that it might still be a bargain for a multibit design etc certainly doesn't make the bug less annoying to me. That's all I meant.
Schiit has been very clear that they don't know what's causing this problem. It's not "hands-off," it's just that there's some subtle interaction they haven't been able to replicate reliably. Race conditions in digital hardware/software are hell to pin down, and this one smells a lot like one. BTW, has anyone tested whether gapless vs gappy play makes a difference to this bug?
I'm in tech as well, and believe me, if I ship software to a customer that contains a bug, he won't care whether it is the consequence of an off-by-one or a very subtle to trigger race. When it happens (and you are right, with an increasing complexity in both hardware and software, issues become more and more subtle), the very minimum I owe the customer is to prevent from making any reassuring claims before the problem is fully understood. I'm sorry but reading premature claims of the affected population with a very low percentage dropped, then reading a message of the manufacturer describing how the hardware may self-heal during the burn-in process is a little hard to digest.
Return the unit and move on. Not sure what you expect them to do, they can't replicate it even on the returned DACs. I had it happen to me in the early stages, powered off, powered on, it hasn't happened since. I fail to see in any aspect of this issue where Jason and Mike have gone wrong.
Collot I think you make many good points. However, this is not a technical forum. It is a hobby one and it is for this reason there is at times rampant fanboyism! It is not - incidentally - Mike and Jason's fault this has occurred.
What you seek in terms of technical clarity isn't here
The problem with OlegPA was that several of us tried to point him to posts and threads that might help answer his questions, but he seemed not to follow up these suggestions seeking instead answers we could not give and Schiit never give.
As for Mike - who is (extremely) highly technically skilled, I saw he asked all affected to let him know whether or not the problem persisted. I think you may have a point if indeed Mike imputed self-healing properties to Bimby eek but I would be (very) surprised if he doesn't continue to take these issues seriously all the same.
Good luck resolving your issue - and welcome to head-fi
It didn't work on two units I have. I would call it a temporary, if not a momentary fix. I've tried both units on Windows 7 & 10, three different usb cables and even a powered hub.
... I'm left in a position now where both my options are not satisfactory: 1) live with a buggy DAC and wait for a solution that might never come, or 2) be stuck with an outdated version of a " futureproof" DAC...
Return the unit and move on. Not sure what you expect them to do, they can't replicate it even on the returned DACs. I had it happen to me in the early stages, powered off, powered on, it hasn't happened since. I fail to see in any aspect of this issue where Jason and Mike have gone wrong.
Did you read what the guy actually said before offering your curt advise? If power off, power on didn't work for you (as multiple have reported) it's likely you would be singing a different tune.
I really admire Schiit and think they have done the entire industry a real favor (probably multiple times). On the other hand the Schiit fanboi crowd's rush to shut down others is annoying, unhelpful and unneeded.
Maybe going back and reading through several of Jason's past posts for style tips would be a good idea.
Btw, I know the manufacturer communicated a low percentage of similar issues reported, but I would take it with a grain of salt: in the wonderful world of support, few people dare to report, and out of those who do not report anything are a majority of people who do not use a certain problematic feature (e.g: rate switching). I hope not but It's still entirely possible that this issue affects all the devices :/
Are we from the same planet and dimension? I bolded the part that I think is the exact opposite of how people behave in my reality. Now add in audiophiles who are crazypants about this hobby.
Chances are good that the problems are over-reported, not under-reported.
Did you read what the guy actually said before offering your curt advise? If power off, power on didn't work for you (as multiple have reported) it's likely you would be singing a different tune.
I really admire Schiit and think they have done the entire industry a real favor (probably multiple times). On the other hand the Schiit fanboi crowd's rush to shut down others is annoying, unhelpful and unneeded.
Maybe going back and reading through several of Jason's past posts for style tips would be a good idea.
I had no intent to be curt or rude, if I came off in that way, then I definitely apologize. But, We obviously have differing opinions on what is reasonable expectations of consumer product support. I believe that Schiit will continue to work this problem and if it is on their end, they will fix it and they will make it right for those affected. I guess if believing in a company makes me a "Schiit fanboi", I am guilty as charged.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
eek
