Printable View
I have a no lock phenomen in auto mode with my Squeezebox devices, manual works just fine (without audible problems). In auto mode it detects the signal for a fragment of a second, then skips the input, rotates over teh other inputs, detects for a split second etc...Quote:
Have other BM owners had issues with the DAC not locking onto signals coming into the coaxial inputs or perhaps not working correctly on any input?
See my post #1197, Dave. It only happened with my Sky HD box and Stan has sent me revised firmware that fixed it.
The BM has been back to Stan and he has installed the new firmware Martin, the issue is still there however. I am beginning to think there is a specific fault with this particular unit as I had to reset it again today. I can't rely on it to work from switch on or when changing inputs, without having to turn it off and back on again :scratch:
Ah ok, sounds like it might be a faulty one.
It's the code hack that was done to bypass the auto function. It was done in haste to satisfy a particular request, but it seems to have a function call hidden somewhere inside the C code that is misbehaving.
The later firmware has a signal lock correction for things like the SB and Airport Express. It's the buffering delay in the SB when it temporarily stops decoding the audio whilst grabbing more audio data from the server supplying it with music. That buffering delay from the SB can be long enough for the BM to think that the SB has stopped operating, in which case the auto search will shoot off to look for a new valid audio source. email me so I can cross check if you have the SB update in the firmware or not.Quote:
Originally Posted by nightyy
I have enough requests for this to justify a proper code rewrite instead of a quick hack. Anyone who needs this feature for important operational reason should email me. I can then put your email in a notification list. Don't PM me if you would like to be on the list or if you have any important technical questions.Quote:
Originally Posted by nightyy
I posted a picture of the alpha version of the BM with USB in a thread. I am making some changes and improvements based on suggestions and observations by a Danish and an Italian beta tester.Quote:
Originally Posted by tadatin
Just a quick update on the USB version of the Bushmaster.
Due to a recent set of agreements with a couple of component manufacturers I have managed to get hold of some additional information on certain components. One set of that data will allow me to do some exciting things, like the ability to take an adaptive or isynchronous data stream from TOSLINK, coax or USB, and buffer it, before using an asynchronous process to sort out jitter. What that means is that in the case of the USB connection method no proprietary drivers are required to be installed on your computer in order to obtain an asynchronous data delivery at the input of the DAC chip. That also means that the TOSLINK and coax data stream will be treated in an asynchronous way once they enter the DAC.
I am not sure about how it all works, but I have been testing it on a modified BM at 24/192KHz with a TOSLINK lead that is less than 3mm thick. I'll have to look for a volunteer or two to double check my results since I am a bit cautious with this asynch malarkey.
The other one is no less exciting. It is not uncommon to see DAC specs mentioning upsampling to 192KHz. I have had a play with a couple but found the audio of an upsampled 44.1Kz file to 192KHz to sound softer. In some cases the tense fast paced action had been converted to a dragged out drama so to speak. This alternative DAC chip approaches the data quite differently however. It processes that data in its original sample rate, but in a 24 bit domain.
So what's different with that compared to upsampling you ask. Well upsampling to 192KHz requires additional padding bits to make up the longer byte. I reckon that it is these extra bits that can make the audio sound softer. But processing in the 24 bit domain is quite often used in the recording and mastering process, after which an audio file can be converted to a 16 bit/44.1KHz CD track for instance by removing 8 bits somehow. Don't ask me how they do it. I have absolutely no idea. The new data I now have in my possession is quite vague in how the process works as far as processing any audio file between 12 to 24 bits in the 24 bits domain is concerned, but I am busy designing a test platform that can only go up to 16 bits, and another platform that uses the 24 bit processing method. That should give me a chance to hear if there are any positive and/or negative effects from using the 24 bit process when a 16 bit audio file is played back. I don't expect any difference with a regular 24 bit audio file, but I shall test that as well just in case.
So what has this got to do with the USB DAC? Well I can't afford to invest in the production of a USB DAC now, whilst sitting on such important information. I feel that since I am still in the preproduction stage of the USB DAC I can take a gamble and take a financial hit on the costs of the R&D of the current USB DAC development, and switch to building a new DAC with the new technical specs. I try to innovate instead of copy. If I wait till I design a next DAC range after the existing or planned one, my competitors might already be using the latest process. But scrapping the existing USB production plan and starting all over again will mean additional delays. It could be an expensive gamble, with no certainty of commercial success afterwards. So any input from other AoS members would be very helpful.
I would love to volunteer BUT need the variable output :(