Page 16 of 24

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 12:23 pm
by Aleg
For those looking for a Beaglebone Black Rev.B, they are in stock here http://www.watterott.com/en/BeagleBone-Black

Cheers

Aleg

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 12:52 pm
by nige2000
Aleg wrote:For those looking for a Beaglebone Black Rev.B, they are in stock here http://www.watterott.com/en/BeagleBone-Black

Cheers

Aleg
thats good

i have one on the way should have it by end of wk

still pondering the ultimate/half decent i2s dac solution
i will likely try to shoehorn something cheap together

has anyone figured out how to utilise the mclk input into the bbb yet? i didnt find much about it yet

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 1:16 pm
by Aleg
nige2000 wrote:
Aleg wrote:For those looking for a Beaglebone Black Rev.B, they are in stock here http://www.watterott.com/en/BeagleBone-Black

Cheers

Aleg
thats good

i have one on the way should have it by end of wk

still pondering the ultimate/half decent i2s dac solution
i will likely try to shoehorn something cheap together

has anyone figured out how to utilise the mclk input into the bbb yet? i didnt find much about it yet
Nigel

I have found a lot of information. Also for putting BBB in mode for either Clock Master or as Clock Slave.
It still is a collection of loose snippets of information. The overall picture hasn't become clear yet. Esp. which component / program has to do what. A lot can and needs to be configured on the BBB esp. due to the mux-ing of the available pins.
Also some information that suggests it requires adaption of the Linux kernel itself in order to configure the devices.

Sounds complicated but maybe some of these thing have already been done by the programmers of players that support I2S communication.

The BBB can be put into slave mode and obtaining the clock from external source.

Esp this post gives a lot of detailed information, but not yet about the slave mode:
http://www.element14.com/community/comm ... ment-30847

Cheers

Aleg

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 2:20 pm
by LowOrbit
Aleg

That's a great piece of detective work. If we could sync both BBB and dac from one high precision clock we would be in a very good place.

Nige, there are a couple of ESS Sabre 9023 dacs on Ebay I think (Hifimediy, being the obvious example) which can be bought with on board clock so will run asynch. That would be a good starting point.

Compared to commercial products the TPA Buffalo (whilst certainly not cheap to implement properly) is well priced and can yield very, very good results.

Mark

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 3:50 pm
by jkeny
It gets a bit more complicated than just using one high-precision audio clock that everything is synched to - you need 2 such clocks - one for each speed family (44.1 & 48KHz) - if you want to be able to deal with all samplerates?. This means you need to sense the samplerate of the incoming audio stream & switch to the correct audio clock. This can add up to a more complex scenario.

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 4:07 pm
by Aleg
jkeny wrote:It gets a bit more complicated than just using one high-precision audio clock that everything is synched to - you need 2 such clocks - one for each speed family (44.1 & 48KHz) - if you want to be able to deal with all samplerates?. This means you need to sense the samplerate of the incoming audio stream & switch to the correct audio clock. This can add up to a more complex scenario.

I have my eye also on a I2S DAC (a NOS one) that appears to be doing reclocking.
Don't know yet if that will circumvent this issue. Idon't have yet that much info about how it will work.

Cheers

Aleg

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 5:26 pm
by jkeny
Aleg wrote:
jkeny wrote:It gets a bit more complicated than just using one high-precision audio clock that everything is synched to - you need 2 such clocks - one for each speed family (44.1 & 48KHz) - if you want to be able to deal with all samplerates?. This means you need to sense the samplerate of the incoming audio stream & switch to the correct audio clock. This can add up to a more complex scenario.

I have my eye also on a I2S DAC (a NOS one) that appears to be doing reclocking.
Don't know yet if that will circumvent this issue. Idon't have yet that much info about how it will work.

Cheers

Aleg
Yes, there are other types of re-clocking - asynchronous clocking that doesn't re-sample the data (as an ASRC does) but it will miss or repeat samples periodically. Maybe this is the scheme being used in the NOS DAC you are looking at? Some people report this type of scheme sounds good, anyway.

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 5:39 pm
by Aleg
jkeny wrote:
Aleg wrote:
jkeny wrote:It gets a bit more complicated than just using one high-precision audio clock that everything is synched to - you need 2 such clocks - one for each speed family (44.1 & 48KHz) - if you want to be able to deal with all samplerates?. This means you need to sense the samplerate of the incoming audio stream & switch to the correct audio clock. This can add up to a more complex scenario.

I have my eye also on a I2S DAC (a NOS one) that appears to be doing reclocking.
Don't know yet if that will circumvent this issue. Idon't have yet that much info about how it will work.

Cheers

Aleg
Yes, there are other types of re-clocking - asynchronous clocking that doesn't re-sample the data (as an ASRC does) but it will miss or repeat samples periodically. Maybe this is the scheme being used in the NOS DAC you are looking at? Some people report this type of scheme sounds good, anyway.

It has been announced in this post on runeaudio forum
http://www.runeaudio.com/forum/mpd-is-n ... .html#p384

Not much has been published about it.

Cheers

Aleg

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 5:47 pm
by jkeny
Aleg wrote: It has been announced in this post on runeaudio forum
http://www.runeaudio.com/forum/mpd-is-n ... .html#p384

Not much has been published about it.

Cheers

Aleg
Ah, yes, I suspect it is using an ASRC chip to resample & reclock the audio stream - nothing wrong with that - it will probably work very well particularly with PCM1794 in NOS mode (digital filters turned off)

Re: Tweaker's Rash

Posted: Tue Feb 25, 2014 7:52 pm
by jkeny
Nige,
The problem with using your RPi with USB DAC may be to do with the block size of the drive that your music is stored on?
http://www.pinkfishmedia.net/forum/show ... stcount=66
The issue is the read block size. Stuttering occurs when the data can't be read and written fast enough, i.e. if it's "biting off more than it can chew" in one go. If the problem persists with a USB hard drive, it will be because the block size with which the drive was formatted (amount of data read in one go) is too high. I formatted my drive with a small block of 1024 bytes and have perfect playback.

So basically give it smaller bite sized pieces so that it can "chew and swallow" fast enough to feed the data smoothly on into the USB DAC.