DSPRelated.com
Forums

What's the use of a 192 kHz sample rate?

Started by Green Xenon [Radium] May 3, 2008
Hybrid wrote:
>> Would you mind explaining how and in what circumstances raising the >> sample rate reduces latency? For a low-pass FIR filter at a given >> frequency -- not a given fraction of the sample rate -- the latency >> remains the same because the number of taps is proportional to sample >> rate. > Lowering latency in the converters will make it easier to use latency > introducing FIR or look ahead limiters. It will not make FIR filters > "faster". > > The reason for my posting was a series of comments at the beginning of the > thread that stated that 192kHz was just a marketing thing to make people > pay more money. In reality there is no reason why pro-audio and consumers > should have different sampling rates. When storage becomes cheaper and > 24/192 should be the standard. Why not?
So you're saying that 24/192 doesn't improve delivery to consumers, but as it simplifies the overall process chain, why not? Compatibility may be one reason why not, but incompatibility can be a powerful marketing tool. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
"Piergiorgio Sartor"
<piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de>
wrote in message news:fftbf5-5k4.ln1@lazy.lzy

> So, he was asking what could it be, are there any > difference between CDs of different batches, maybe. > They told him something about jitter, it seems > different CDs can have different jitter. > > He, then, took some high end CD player and measured > all he could measure, including jitter, of different > copies of the same CD(s). > > He could not find anything strange, the high end CD > player has FIFOs, which keep the jitter constant and > minimum (low end is different story, but audiophiles > use high end).
In fact all CD players have a FIFO or something like it, which reduces the natural high jitter of the data coming off the CD. If there's jitter in a CD player, it has to be locally-generated.
>So you're saying that 24/192 doesn't improve delivery to consumers, >but as it simplifies the overall process chain, why not?
Well, I'm of the opinion that the Nyquist theorem was a real piece of genius. With that in mind the logical part of my brain tells me there should not be any improvement by going to higher sampling rates. Problem is that plenty recording and mastering engineers have never heard of Nyquist and they break one of the ""laws": They change the frequency spectrum through their use of digital clipping. It is not as obvious to them because they have pro converters that can handle severe +dBFS situations and they listen at higher sampling rates (and the higher low-pass frequency that comes with it). So the engineer is happily unaware of the 10% distortion that the mix will result in when the consumer tries to enjoy his newly bought CD. So, I'm saying it is the degradation (the process of making it a 16/44.1 CD) to a consumer product that introduces a some of the distortion we hear on todays CD's. This is why consumers should have access to the music at its original bit depth and sampling frequency - so in reality it is improving what the customer hears. (that is of course if the recording enginners has any ears to begin with) L
Hybrid wrote:
>> So you're saying that 24/192 doesn't improve delivery to consumers, >> but as it simplifies the overall process chain, why not?
> Well, I'm of the opinion that the Nyquist theorem was a real piece of > genius. With that in mind the logical part of my brain tells me there > should not be any improvement by going to higher sampling rates. Problem is > that plenty recording and mastering engineers have never heard of Nyquist > and they break one of the ""laws": They change the frequency spectrum > through their use of digital clipping. > It is not as obvious to them because they have pro converters that can > handle severe +dBFS situations and they listen at higher sampling rates > (and the higher low-pass frequency that comes with it). So the engineer is > happily unaware of the 10% distortion that the mix will result in when the > consumer tries to enjoy his newly bought CD. So, I'm saying it is the > degradation (the process of making it a 16/44.1 CD) to a consumer product > that introduces a some of the distortion we hear on todays CD's. > This is why consumers should have access to the music at its original bit > depth and sampling frequency - so in reality it is improving what the > customer hears. (that is of course if the recording enginners has any ears > to begin with)
Got it: 24/192 is a Bandaid for incompetence. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
On Thu, 08 May 2008 14:43:34 -0400, Jerry Avins <jya@ieee.org> wrote:

>Eric Jacobsen wrote: >> On Thu, 08 May 2008 12:12:52 -0400, Jerry Avins <jya@ieee.org> wrote: >> >>> Hybrid wrote: >>> >>> ... >>> >>>> Just a few years ago it was no uncommon to see 5-10ms latency through >>>> almost any typical digital effects box or loudspeaker management system. >>>> This was an issue that has been reduced a great deal thanks to higher >>>> sampling rates _and_ the technology that came along with that. >>>> Now imagine that a live situuation had to process the audio through 5-10 >>>> such digital devices and the latency will make it difficult to play on >>>> stage. >>> Would you mind explaining how and in what circumstances raising the >>> sample rate reduces latency? For a low-pass FIR filter at a given >>> frequency -- not a given fraction of the sample rate -- the latency >>> remains the same because the number of taps is proportional to sample rate. >>> >>> Jerry >> >> If there are block-oriented processes, like FFTs, in the chain then >> increasing the sample rate can help even if the processing rate of the >> block isn't improved. This is because the block doesn't have to wait >> as long to get filled, and can therefore generate an output more >> quickly. > >An FFT of the same bin separation needs to be twice as long, so where's >the improvement?
In some cases, like FFTs, keeping all the same assumptions doesn't necessarily yield any improvement. If, however, the goal is strictly to reduce latency, in some cases (certainly not all), oversampling allows collection of enough data to facilitate a decision or action more quickly. A PLL with a high input rate can support a wider loop bandwidth and, therefore, respond more quickly than a loop with a lower sample rate and tighter loop. The reduction in latency may not be large, and I don't think one can count on it in every circumstance (or even most, perhaps), but it can be exploited in some conditions.
>> There's a similar situation that happens in carrying comm traffic with >> latency-sensitive applications (like voice). If the data rate of the >> signal is low the latency suffers, and one way to fix it is to >> multiplex the sensitive channel into a stream with a much higher bit >> rate. It doesn't eliminate delays, but it can reduce them >> substantially. > >Doesn't that amount to doing more tasks at the same time? Why does that >speed any one task?
Again, if the goal is to reduce the latency for a particular task (or channel) and one way to do it is to group it with other tasks/channels, then that's certainly an option that can be exploited. Even if the net processing load increases (which it may not), that may still be an adequate tradeoff to reduce latency for one or some channels/tasks. In the comm case, an easy example is a channel with high-gain block coding. Usually in order to get the most gain the block needs to be long (say, for a Turbo Code or LDPC). If the bit rate of the channel is low, it takes a long time to collect that block of data before the decoder can even start processing it. If the bit rate is very high, even if the channel is shared with other users, the latency associated with collected the code block goes way down. Since that can help on both the encoding and decoding side, there's significant latency improvement to be had. Likewise with interleavers/deinterleavers, etc., etc. Generally on tries to put latency sensitive channels in high-bandwidth pipes partly for these reasons. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
In article <ltudnZJaF7ZP_77VnZ2dnUVZ_r2nnZ2d@comcast.com>,
Arny Krueger <arnyk@hotpop.com> wrote:

>> He could not find anything strange, the high end CD >> player has FIFOs, which keep the jitter constant and >> minimum (low end is different story, but audiophiles >> use high end). > >In fact all CD players have a FIFO or something like it, which reduces the >natural high jitter of the data coming off the CD.
Yup. There has to be, because the data coming in from the CD and its low-level demodulator has to be buffered up and fed into a two-level cross-interleaved Reed-Solomon error-correction decoder. The data coming out of the error correction logic is at a significantly lower bit-rate than the raw data coming in from the CD read assembly, and the bits are in a very different ordering. There's also quite a bit of "wow" in the rate of the data being read from the CD... the CD's motor speed is being adjusted dynamically "on the fly" in order to keep the amount of data in the de-interleaver and Reed-Solomon decoder from rising too high (which would overrun the buffer memory) or too low (which would result in the data stream to the DAC chip running out). Every single-box CD player I know of, from the very earliest days until now, has incorporated this sort of buffering and FIFO in its decoder chip, and has clocked the data into its DAC-chip based on a signal from an onboard quartz oscillator. As long as the quartz oscillator is stable (good power, adequate protection against microphonics) there should be little jitter in the timing of the digital-to-analog conversion. Two-box playback systems (a CD transport with the Reed-Solomon decoder, and a separate DAC-box or A/V amplifier, connected via S/PDIF or a similar digital pathway) actually have a harder job of it, because the DAC-box doesn't have direct access to the stable quartz- oscillator signal that drives the Reed-Solomon decoder. Such setups must "recover" stable clock timing from the incoming S/PDIF or other digital-audio signal, and this is a nontrivial process and is sometimes done rather badly. This is a case of "pay more, and get more problems rather than less". -- Dave Platt <dplatt@radagast.org> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do _not_ wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads!
In rec.audio.tech Jerry Avins <jya@ieee.org> wrote:
> Steven Sullivan wrote: > > In rec.audio.tech Jerry Avins <jya@ieee.org> wrote: > >> Steven Sullivan wrote: > >>> In rec.audio.tech rickman <gnuarm@gmail.com> wrote: > >>>> On May 3, 8:22 am, nos...@nospam.com (Don Pearce) wrote: > >>>>> On Sat, 3 May 2008 05:11:53 -0700 (PDT), rickman <gnu...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> On May 3, 3:28 am, Randy Yates <ya...@ieee.org> wrote: > >>>>>>> rickman <gnu...@gmail.com> writes: > >>>>>>>> If it really is a waste of time and money to use 192 kHz ADC and DAC, > >>>>>>>> why do you think they would do it? > >>>>>>> Greed. They think that the general public is dumb enough to buy into > >>>>>>> the lie that they really need such a system and would then spend lots of > >>>>>>> money repurchasing what they already have. > >>>>>> I'm curious, how do you know what unnamed people are thinking? My > >>>>>> understanding is that regardless of what frequencies acoustic testing > >>>>>> says that people can hear, audiophiles can hear the difference between > >>>>>> many of these "wasteful" features and otherwise adequate audio > >>>>>> systems. > >>>>> Utter nonsense - unless of course you can cite some proper tests. > >>>> And what do you base this statement on? I don't have any "proper" > >>>> studies. I am referring to a conversation with a friend who worked in > >>>> the field. > >>> > >>> Not nearly good enough. > >>> > >>> > >>>> You can poo-poo this sort of evaluation. But that doesn't make you > >>>> right. Do you have any "proof" that no one can hear the difference? > >>>> Do you even know what the differences are that I was talking about? > >>> You can't prove negatives to 100% empirical certaintly. You can determine likelihoods, and > >>> that's what science is really about -- finding the models of reality that are most likely > >>> to be accurate. It seems extremely likely, for example, that no one can actually *hear* > >>> frequencies above the mid-20 kHz. They can be perceived via bone conduction, if the signal is > >>> generated right at the skin surface. > > > >> Conduction to the inner ear and thence via the auditory nerve? > > > > > > I didn't say 'heard' (implying participation of the auditory nerve). I said 'perceived'.
> I can perceive a light bulb in contact with my skin going on and off. Do > you call that bone conduction too?
No, but I don't call it 'seeing' either.
> According to my audiologist, "bone > conduction" is an alternate pathway to the auditory nerve.
one that bypasses the hair cells? -- -S maybe they wanna rock. maybe they need to rock. Maybe it's for the money? But That's none of our business..our business as fans is to rock with them.
Steven Sullivan wrote:
> In rec.audio.tech Jerry Avins <jya@ieee.org> wrote:
...
>> According to my audiologist, "bone >> conduction" is an alternate pathway to the auditory nerve. > > one that bypasses the hair cells?
No. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Eric Jacobsen wrote:

   ...

> In the comm case, an easy example is a channel with high-gain block > coding. Usually in order to get the most gain the block needs to be > long (say, for a Turbo Code or LDPC). If the bit rate of the channel > is low, it takes a long time to collect that block of data before the > decoder can even start processing it. If the bit rate is very high, > even if the channel is shared with other users, the latency associated > with collected the code block goes way down. Since that can help on > both the encoding and decoding side, there's significant latency > improvement to be had. Likewise with interleavers/deinterleavers, > etc., etc. Generally on tries to put latency sensitive channels in > high-bandwidth pipes partly for these reasons.
But the sample rate of any one channel isn't increasing. Is it possible that Hybrid is confused about his claim? Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Piergiorgio Sartor wrote:
> Steven Sullivan wrote: > >> *Maybe* your friend was imagining things. > > Exactly! > I was close to say that *maybe* the Earth is flat. > > With this kind of reasoning, everything is possible. > > I tell you another story. > > Once I met another guy, responsible of the quality > in one audio CD factory. > He told me that, looking for quality, they asked > also audiophiles about what they think. > It turned out that some people buy 2~3 copies of the > same audio CD, they "test" it at home, and then keep > the one that "sounds better".
This notion might be a hangover from a genuine issue in the early days of CDs. They used to struggle to make them, and many had pin prick holes through the metalisation. You could hold them up to the light, and easily see those holes. Wrapped in plastic in the shop you couldn't see these flaws. I knew an early adopter who would go through several copies until he found one that looked and played flawlessly.
> So, he was asking what could it be, are there any > difference between CDs of different batches, maybe. > They told him something about jitter, it seems > different CDs can have different jitter. > > He, then, took some high end CD player and measured > all he could measure, including jitter, of different > copies of the same CD(s). > > He could not find anything strange, the high end CD > player has FIFOs, which keep the jitter constant and > minimum (low end is different story, but audiophiles > use high end).
They all have FIFOs. The data isn't played directly from the disk. It is played from the ECC decode buffer. It is clocked from there to the DAC by a stable clock. It would take a pretty broken design to have so much phase noise in that clock that it produced significant jitter.
> In the end he could not figure it out what was the > reason why different copies of the same CD should > sound differently. > > Next reply I'll tell you another of this stories.
Regards, Steve