PDA

View Full Version : SB2: A couple of questions and a suggestion



Mike Hartley
2005-03-09, 17:12
Sean,
A couple of questions regarding the design. First, where did you guys get the idea of doing all of the DSP work in software? Is this yours from the ground up? And second, you talk about the seperate data paths for the analog and s/PDIF. When you say you can output the digital stream to an AV receiver and a seperate rendition to the analog outs, where would the seperate data stream come from? If you could elaborate a little on what you were thinking I'd appreciate it. Also, rather than seperate renditions of the same file, you might want to consider the option of sending one title to the analog and one to the digital. I know there are many interface challenges to this suggestion, but many AV receivers have zone two capability that allows you to listen to different content in each zone and in most that capability is limited to analog input. This split would allow you to play different titles in zone one and zone two using one receiver. In the current scenario, you would have to listen to the same content in both zones.

Mike

-----Original Message-----
From: Sean Adams [mailto:sadams (AT) slimdevices (DOT) com]
Sent: Wed 3/9/2005 6:22 PM
To: Slim Devices Discussion
Cc:
Subject: Re: [slim] SB2 and PCM formats




The DAC is rated for 96KHz.... anyway for DVD audio you'd probably want
to use the s/pdif.


On Mar 9, 2005, at 3:16 PM, Steinar Bjaerum wrote:

> This means that, in theory, SB2 is capable of playing 2-channel high
> resolution 192/24 DVD-Audio both to analog and digital output?
>
> Steinar
>
>> -----Original Message-----
>> From: discuss-bounces (AT) lists (DOT) slimdevices.com [mailto:discuss-
>> bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Sean Adams
>> Sent: 9. mars 2005 22:10
>> To: Slim Devices Discussion
>> Subject: Re: [slim] SB2 and PCM formats
>>
>>
>> DISCLAIMER: please be very clear that these are not promises that
>> we're
>> going do any particular feature at any particular time, or even at
>> all.
>> I will comment *to the best of my knowledge* on what the hardware
>> could
>> potentially be made to do, but please don't hold me to it if we find
>> some reason later why some particular thing can't or won't be done.
>>
>> Right now Squeezebox2 does 24 bits (s/pdif and DAC) at 44.1 and 48KHz.
>>
>> A block diagram is in order:
>>
>>
>> ----------------
>> | ip3023 cpu |
>> ----------------
>> |
>> |
>> ----------------
>> | |----- 11.2896 mhz
>> |xc9536xl CPLD |
>> ---| |----- 12.2880 mhz
>> | | |
>> | ----------------
>> | | | -------------------
>> | | |_________| S/PDIF outputs |
>> | | -------------------
>> | -------
>> | | DAC |
>> | -------
>> | | -------- ______________
>> | +--------| AMP |------| RCA Outputs |
>> | | -------- --------------
>> | |
>> | ---------- --------- --------------
>> +----| CMOS |----| AMP |------| Headphone/ |
>> | | SWITCH | --------- | geekport |
>> | --------- ---------------
>> | |
>> |------------------------------------|
>>
>>
>>
>> The really important thing to note here is that there are NONE of the
>> usual "hard-wired" digital audio components that you'd expect to see.
>> S/PDIF outputs are usually done using a chip like the CS8405. Also,
>> often times there will be some "audio codec" chip in the path, which
>> handles gain, mixing, resampling and stuff like that. We are doing ALL
>> of this stuff in software, which gives us tremendous flexibility to
>> tweak, tune, and improve it.
>>
>> The other important point is that the digital logic which handles the
>> s/pdif outputs and the feeding of data to the DAC is all done in a
>> Xilinx gate array. If you're not familiar with CPLDs or FPGAs,
>> basically the idea is that instead of hard-wiring a bunch of
>> individual
>> logic chips together or making a custom integrated circuit, these
>> programmable gate arrays allow you to create your own custom chip by
>> writing code. The _really_ killer thing about them is that you can
>> reprogram them later, which in terms of standard logic chips, is the
>> equivalent of making a whole new circuit board in "software". In
>> squeezebox2 this Xilinx chip is configured by the CPU, so we have the
>> ability to completely "rewire" the digital output path just about any
>> way we want, at any time. Hence there are some extremely interesting
>> possibilities for future features....
>>
>> Finally, notice the geekport. Squeezebox1 had a geekport too, but it
>> was not really accessible because you had to open the case and solder
>> stuff onto the board. In Squeezebox2, the geekport is the headphone
>> jack! The headphone jack can be reconfigured for other modes,
>> including
>> bidirectional data and IR blasting. These features are not done yet
>> but
>> the hardware support is there.
>>
>> Everything below this line is a ** POSSIBLE MAYBE SOMETIME DOWN THE
>> ROAD **.
>> --------------------
>>
>> - The hardware has SEPARATE DATA PATHS for s/pdif and DAC outputs. We
>> are not using this capability now (both are fed the same data), but it
>> could be used perhaps for some interesting multi-channel applications.
>> For example, we could output the encoded digital stream to a surround
>> receiver, and also output a 2-channel stereo rendition to the DAC.
>>
>> - Crsytals can easily be desoldered. The logic is driven directly by
>> these two oscillators, so if you want to experiment with unusual
>> frequencies or wire up an aftermarket clock source, you can.
>>
>> - 96Khz should be doable with the xtals we have, maybe 192.
>>
>> - All the s/pdif data is under our control. We can pretend to be
>> AES/EBU, lie about what kind of device we are (DAT player etc), shut
>> off the s/pdif in order to tell an amp or receiver that we're not
>> active, etc etc.
>>
>> - There are some vendor-specific/proprietary tricks that some guys are
>> doing with s/pdif. In particular, I believe somebody has a receiver +
>> s/pdif speaker setup that sends volume commands over the s/pdif. We
>> could support things like this - probably they would be trivial to
>> reverse-engineer, but we'd prefer to get cooperation.
>>
>> - The geekport can potentially do some pretty crazy things - high
>> speed
>> RS232 for example, auxiliary s/pdif output, house sync (word clock)
>> input, maybe even s/pdif INPUT, i2c, dallas 1-wire - damn near
>> anything
>> you can do on two wires + ground. The only geekport feature we're
>> aiming to finish by ship date is IR blasting. This will allow
>> Squeezebox2 to power on your receiver and set it to the right input,
>> and later power it off automatically when you're done listening. The
>> IR
>> blaster has a variable current driver so it can be set up to drive a
>> single LED dimly up to multiple LEDs brightly. It could also deliver
>> enough current to drive a small external voltage regular eg for a
>> microcontroller which would communicate with the SB2 over dallas
>> 1-wire.
>>
>>
>>
>>
>> On Mar 9, 2005, at 11:44 AM, Steinar Bjaerum wrote:
>>
>>> What PCM formats are the DAC in the SB2 capable of delivering to the
>>> analog
>>> output?
>>> All the way up to 96kHz/24bits?
>>>
>>> What PCM formats are SB2 capable of passing through to the S/PDIF
>>> digital
>>> out?
>>>
>>> I am interested in knowing both the current status and the
>>> possibilities
>>> with future software upgrades.
>>>
>>> Steinar
>>>
>>>
>>>

seanadams
2005-03-09, 17:42
> A couple of questions regarding the design. First, where did you guys
> get the idea of doing all of the DSP work in software?

Mike,

Doing all the DSP in software (as opposed to fixed-function chips) is
more difficult but it's the right thing to do. Generally a/v products
are using less and less specialized hardware for signal processing,
because general purpose processors are now so cheap.

> Is this yours from the ground up?

Vidur did most of the DSP work, including porting mp3 (based on
Underbit MAD) and getting all the new bufferin, crossfading, and
visualizers in place. I did the logic design and the software s/pdif
driver.

> And second, you talk about the seperate data paths for the analog and
> s/PDIF. When you say you can output the digital stream to an AV
> receiver and a seperate rendition to the analog outs, where would the
> seperate data stream come from?

S/PDIF has an extension for compressed bitstreams. This is how DVD
players send 5.1 audio to a receiver over s/pdif. Our CPU could pass
the compressed 5.1 bitstream out the s/pdif, and simultaneously
decompress and feed a stereo signal to the DAC.

> Also, rather than seperate renditions of the same file, you might want
> to consider the option of sending one title to the analog and one to
> the digital.

Yep, another possibility. You could do a laser show by driving a pair
of galvanometers off the analog outputs while playing the audio out of
the s/pdif. :)

> I know there are many interface challenges to this suggestion, but
> many AV receivers have zone two capability that allows you to listen
> to different content in each zone and in most that capability is
> limited to analog input. This split would allow you to play different
> titles in zone one and zone two using one receiver. In the current
> scenario, you would have to listen to the same content in both zones.

We're all for suggestions...