Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

Steve Underwood wrote:

> They all have FIFOs. The data isn't played directly from the disk. It is 

Uhm, this is a misconception of CD player.
One thing is to have a 8KiB FIFO, one is to have a
16Bytes FIFO.

Said that, performance of CD players changes from
low to high end.

And here it comes another story.

Once I payed a visit, with a friend of mine, to one
of this guys with super-cables concepts.
He had an high end system, with these oxygen-free,
carbon-diffused, time-warped, whatsover cables.
He, of course, said these cables are needed for the
ultimate audio experience.
So, we listen the music with these cables and with
the normal ones, on his high end system.
Myself, and the friend, could not really feel any
difference.
We decided to try the super-cables with the low end
system that the friend of mine had. Really a cheap CD
player.
Well, the cables made a huge difference, in that setup,
even better than the high end.

bye,

-- 

piergiorgio

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Steven Sullivan wrote:
> In rec.audio.tech Jerry Avins <j...@ieee.org> wrote:
>> Steven Sullivan wrote:
>>> In rec.audio.tech Jerry Avins <j...@ieee.org> wrote:
>>>> Steven Sullivan wrote:
>>>>> In rec.audio.tech Jerry Avins <j...@ieee.org> wrote:
>>>>    ...
>>>>>> According to my audiologist, "bone 
>>>>>> conduction" is an alternate pathway to the auditory nerve.
>>>>> one that bypasses the hair cells?
>>>> No.
>>> Ok, then I *should* call it 'hearing'.
>>>
>>> Now, would it have any relevance to sound that isn't delivered directly
>>> at the body surface?
> 
>> Please spell out "sound that isn't delivered directly at the body 
>> surface" so I don't need to imagine what you might mean.
> 
> You know - normal listening.  Where the sound source isn't pressed
> directly up against your scalp.

I get you. I use a chopstick clamped in my molars to listen for motor 
sounds. Not scalp, but surely bone conduction. It works better than a 
stethoscope. I also feel the bass drum in a parade band as a sensation 
in my chest.

It's a rare recording/speaker that reproduces that sensation. That 
loudspeaker is making sound by any definition, but my perception of it 
isn't hearing. My perception of mechanical vibration with my fingertips 
isn't hearing either, even when the vibration would be audible if it 
reached my ear. People who are stone* deaf can perceive it too.

Jerry
_____________________________________
* Interesting etymology. Not what I would have guessed.
-- 
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Piergiorgio Sartor wrote:
> Steve Underwood wrote:
> 
>> They all have FIFOs. The data isn't played directly from the disk. It is 
> 
> Uhm, this is a misconception of CD player.
> One thing is to have a 8KiB FIFO, one is to have a
> 16Bytes FIFO.

As long as the FIFO sends the bytes out at a constant rate, where is the 
misconception?

> Said that, performance of CD players changes from
> low to high end.
> 
> And here it comes another story.
> 
> Once I payed a visit, with a friend of mine, to one
> of this guys with super-cables concepts.
> He had an high end system, with these oxygen-free,
> carbon-diffused, time-warped, whatsover cables.
> He, of course, said these cables are needed for the
> ultimate audio experience.
> So, we listen the music with these cables and with
> the normal ones, on his high end system.
> Myself, and the friend, could not really feel any
> difference.
> We decided to try the super-cables with the low end
> system that the friend of mine had. Really a cheap CD
> player.
> Well, the cables made a huge difference, in that setup,
> even better than the high end.

I think you must have missed something.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Fri, 09 May 2008 23:12:23 +0200, Piergiorgio Sartor wrote:

> Uhm, this is a misconception of CD player. One thing is to have a 8KiB
> FIFO, one is to have a 16Bytes FIFO.

The buffer has to be at least large enough to hold a sector of data, so 
that the ECC can be decoded.  And then another to catch the next sector 
while the first is cycled out to the D/A.  If you can do that in 16 
bytes, I'd be very surprised.  There's probably also a requirement for 
enough space to deal with per-rotation speed variations.  I suspect that 
several KB is a minimum.

In any case, as Jerry said: there's a buffer, and the data comes out of 
that clocked by a crystal oscillator: where does the buffer size come 
into the equation?

-- 
Andrew

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Andrew Reilly wrote:
> On Fri, 09 May 2008 23:12:23 +0200, Piergiorgio Sartor wrote:
> 
>> Uhm, this is a misconception of CD player. One thing is to have a 8KiB
>> FIFO, one is to have a 16Bytes FIFO.
> 
> The buffer has to be at least large enough to hold a sector of data, so 
> that the ECC can be decoded.  And then another to catch the next sector 
> while the first is cycled out to the D/A.  If you can do that in 16 
> bytes, I'd be very surprised.  There's probably also a requirement for 
> enough space to deal with per-rotation speed variations.  I suspect that 
> several KB is a minimum.
> 
> In any case, as Jerry said: there's a buffer, and the data comes out of 
> that clocked by a crystal oscillator: where does the buffer size come 
> into the equation?
> 

Note only that, but if the FIFO were not big enough, the result would 
not be jitter in the output. It would be very obvious hiccups in the 
sounds. There is just no way a maker can compromise on the FIFO.

Steve

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Steve Underwood <s...@dis.org> writes:

> Andrew Reilly wrote:
>> On Fri, 09 May 2008 23:12:23 +0200, Piergiorgio Sartor wrote:
>>
>>> Uhm, this is a misconception of CD player. One thing is to have a 8KiB
>>> FIFO, one is to have a 16Bytes FIFO.
>>
>> The buffer has to be at least large enough to hold a sector of data,
>> so that the ECC can be decoded.  And then another to catch the next
>> sector while the first is cycled out to the D/A.  If you can do that
>> in 16 bytes, I'd be very surprised.  There's probably also a
>> requirement for enough space to deal with per-rotation speed
>> variations.  I suspect that several KB is a minimum.
>>
>> In any case, as Jerry said: there's a buffer, and the data comes out
>> of that clocked by a crystal oscillator: where does the buffer size
>> come into the equation?
>>
>
> Note only that, but if the FIFO were not big enough, the result would
> not be jitter in the output. It would be very obvious hiccups in the
> sounds. There is just no way a maker can compromise on the FIFO.

You mean the $8000 I spent on that whiz-bang CD "transport" was an
utter waste?!
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <y...@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://www.digitalsignallabs.com

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Jerry Avins wrote:

> As long as the FIFO sends the bytes out at a constant rate, where is the 
> misconception?

That the FIFO cannot go full or empty, the output
rate will be constant "on average".

The problem is that, at least old low end CD player,
do not have the capability to read a data block from
the disk, but only to stream data from it.
Due to several reasons, this stream is not always
constant (in rate), thus FIFOs are needed.
Of course the variance of the stream rate somehow
defines the FIFO size. Or the output of the FIFO
is also modulated in order to follow, at slower
change rate, the changes of the input.
Thus producing jitter, or better, lowering the
jitter of the input.

If you can afford memory, no problem, if you cannot,
then you'll have to change the D/A rate, as in a PLL.

This was confirmed by the CD quality people.

Nowadays, I can imagine that the pick-up can read and
re-read single blocks, even several times, thus creating
a fully random access device, which can rely on a different
buffering mechanism.

[cables]
> I think you must have missed something.

No idea, we were all surprised.
I could imagine several scenarios, but, unfortunately,
I had no chance to measure anything.

bye,

-- 

piergiorgio

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Andrew Reilly wrote:

> In any case, as Jerry said: there's a buffer, and the data comes out of 
> that clocked by a crystal oscillator: where does the buffer size come 
> into the equation?

Let's say the official rate is 2Mbit/sec, with variation
within +/-10%, i.e. from 2.2 to 1.8.

If for 1 second the data rate is 2.2, and then later 1.8
for another second, the FIFO will have to hold enough data
in order to keep the 2.0 constant output.
At the end of the first second, the FIFO will have 2.2 input,
but 2.0 output, thus it must be capable to hold 0.2Mbit, or
around 26KiB.

The higher the variance of the input stream, the more
memory is needed.

This is because you cannot read single blocks, like in
HD, but only start to read from one approximate position
and go on from there.

New devices, as I wrote in the other reply, behave more
like HD, so the buffering system is different and, I
would say, more relaxed.

bye,

-- 

piergiorgio

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Steve Underwood wrote:

> Note only that, but if the FIFO were not big enough, the result would 
> not be jitter in the output. It would be very obvious hiccups in the 
> sounds. There is just no way a maker can compromise on the FIFO.

They change(d) the output rate of the FIFO.
As soon as the it approaches full, the output
rate is increased and the other way around.

It is like in a rate control system or a PLL.

bye,

-- 

piergiorgio

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

"Piergiorgio Sartor"
<p...@nexgo.REMOVETHIS.de> wrote in
message news:m...@lazy.lzy...
> Steve Underwood wrote:
>
> > Note only that, but if the FIFO were not big enough, the result would
> > not be jitter in the output. It would be very obvious hiccups in the
> > sounds. There is just no way a maker can compromise on the FIFO.
>
> They change(d) the output rate of the FIFO.
> As soon as the it approaches full, the output
> rate is increased and the other way around.

No, the *input* rate is changed by varying the speed of the disk motor.

MrT.

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.