Dac not compatable with SBT?

[Soulkeeper]

Have you considered going around the problem by configuring LMS to upsample all 44.1 kHz material to 88.2 kHz, and all 48 kHz material to 96 kHz?

[slimmac]

I have not. Do you have a link you could forward me with instructions on how to achieve this?

Does this affect the sound quality whatsoever?

Have you considered going around the problem by configuring LMS to upsample all 44.1 kHz material to 88.2 kHz, and all 48 kHz material to 96 kHz?

[Mnyb]

I have not. Do you have a link you could forward me with instructions on how to achieve this?

Does this affect the sound quality whatsoever?

No .

You get a higher workload on the server and use more network bandwidth .

But if your server is a PC the transcoding would hardly notice (a NAS another story ) good wifi or wired and bandwidth should not ba an issue .

[Soulkeeper]

Do you have a link you could forward me with instructions on how to achieve this?

Sorry, I don't have any links for you, and I haven't tried to do these changes myself so I have little to add, but if you search this forum for server side transcoding, sox, server side upsampling, lms transcoding, lms upsampling, sox transcoding etc., I'm sure you'll find loads of info. I've seen it discussed many times.

[slimmac]

Well that's great news. I'm using a MAC Pro Tower Dual Processor Quad Core 2.8Ghz for all processing.
Overkill - yes indeed.

This maybe a solution. Thanks guys - much appreciated. I will let you know how it works out.

No .

You get a higher workload on the server and use more network bandwidth .

But if your server is a PC the transcoding would hardly notice (a NAS another story ) good wifi or wired and bandwidth should not ba an issue .

[cfraser]

Have you considered going around the problem by configuring LMS to upsample all 44.1 kHz material to 88.2 kHz, and all 48 kHz material to 96 kHz?

That is a good idea! It might just work.

[What it does is put the sample frequencies that the PLL needs to lock on much closer together i.e. ~8kHz diff rather than ~52kHz diff.]

[JohnSwenson]

What is the firmware version on your Touch? Older firmware had a bug that would rapidly switch to 44.1 on any sample rate change, such as going from 88.2 to 96 it would switch to 44.1 for a few miliseconds which could cause some DACs fits. But you are having problems with 96 to 44.1 so that is probably not the issue.

Let me know what firmware you are using and I'll stick a logic analyzer on the Touch and see what the coax output is doing when changing sample rates. Who knows, it might be doing something strange.

John S.

[Mnyb]

What is the firmware version on your Touch? Older firmware had a bug that would rapidly switch to 44.1 on any sample rate change, such as going from 88.2 to 96 it would switch to 44.1 for a few miliseconds which could cause some DACs fits. But you are having problems with 96 to 44.1 so that is probably not the issue.

Let me know what firmware you are using and I'll stick a logic analyzer on the Touch and see what the coax output is doing when changing sample rates. Who knows, it might be doing something strange.

John S.

Off Topic:
It does according to some Cambridge 840C owners .

http://bugs.slimdevices.com/show_bug.cgi?id=16641 we assumed that this bug is cosmetic only but who knows.

With your detailed knowledge on such topics you may have an opinion on that to.

I emphasise that this has nothing to do with the topic of this tread

[cfraser]

I have used DACs with the SBT that do exactly what the OP is talking about. And still have one...the problem is no mystery to me. It is NOT specifically an SBT problem, it will happen with any source that can drastically change sample rate, with DACs that have this type of clock circuitry. Frankly, DACs that do this *should* be taken out of service, use whatever excuse you want, but clearly I shouldn't have to tell somebody WHY they should get rid of it if they are trying to use it seamlessly in this SBT app (e.g. see this thread), or any app that requires varying sample rates. You won't be able to fix the problem in the DAC. You can usually make it much better, but not totally fix it without way too much work. It's the design. Tons of people have dumped DACs for just this reason. It is kind of a "five years ago" problem. The DACs weren't particularly expensive so people don't complain much by this time, but they sure did when the DACs were new.

I got rid of mine! It was fine when I had to get up anyway to change discs: could just manually force a sample rate change at the DAC. But now that music of all different sample rates can be played in any order with the e.g. SBT, it's a bloody nuisance. And with one DAC we tested, it was even potentially "dangerous" as the DAC could make all sorts of strange loud noises when it didn't lock properly. Ask anyone who's played with a lot of DACs: there's an awful lot of poorly-designed ones out there. Most. People hate being told that their $100 DAC isn't special, don't they, especially here it seems...

[Eric Seaberg]

I've got a Denon receiver that's probably 10-years old. The digital input will take almost ANYTHING I send to it, except for 88.2. IMHO, 88.2 is a stupid SR to use anyway and it's only because of laziness on the original mix engineer thinking conversion from 88.2 to 44.1 is easier. That may have been the case 6-7 years ago, but not anymore. There is no reason higher SR recordings shouldn't standarize at 96k or 192k. This makes them totally compatible with BluRay/DVD players as well.

Regardless, if you're trying to play 88.2 files, or they've been purchased that way (I've bought several 88.2k/24bit albums), up-convert them to 96k. I'm on a Mac and have several programs to do that since I'm in the recording/post-production biz, but I also have dBPoweramp when running my Mac on Windows, and it ROCKS!!

Other than that, I'm not sure what to tell you. All of my HiRes stuff is played on a Transporter, which could make a difference as well. Good luck with your issue.