[meinname123]

I not meant volume sync.
I meant:
When the user enables the option and something is streamed to the es100 then your android or iphone app (also when running in the background) sets the source volume to 0db . And if it gets lowered it just sets the sourcevoulme back to 0db.
So the user can't accidentally lower the source volume on the device and has to control it via the es100 or the analog volume slider.

 

[PiSkyHiFi]

In the meanwhile, Android OS does NOT support the volume synchronization.
No receiver can support the volume synchronization with Android.
Android always scales the PCM down before the Bluetooth encoder, when adjusting Bluetooth volume.
Android Users need to keep that in their mind all the way.

The rule of thumb:

For Android, set the mobile phone volume to the maximum with any Bluetooth receiver.

For iOS, if Bluetooth receiver vol +/- button actions result on iPhone volume popup consequently,
then the receivers supports the volume synchronization.
You don't need to care anything about that.
If not, the receiver doesn't support the volume synchronization,
and you need to set the iPhone volume to the maximum.

Hope this helps you.

Thanks and Regards,
WS

That may be true, but the scaled down volume prior to bluetooth encoding in Android is using a 48KHz 24 bit path. This means the actual issue with volume is to not amplify the noise floor of the ES100 too much with a low volume signal. The ESS 9018 is a great example of a DAC that uses an internal 32 path and digital volume control, because it's analog noise floor is so incredibly low.

The issues with digital volume control is mostly to do with unreliable math in 16 bit. Once we can be certain the math is good, then it comes down to avoiding pushing the analog volume control too hard.

I think anything between 70% and 100% volume on an Android phone that is using AptX HD, would be fine - just basically listen out for the analog noise floor. If you can hear any of it, turn the digital volume up and the analog down.

That's my take on it - this is great little device that get's so much of it right, with the right firmware, this thing is going to be highly sought after.

 

[wslee]

That may be true, but the scaled down volume prior to bluetooth encoding in Android is using a 48KHz 24 bit path. This means the actual issue with volume is to not amplify the noise floor of the ES100 too much with a low volume signal. The ESS 9018 is a great example of a DAC that uses an internal 32 path and digital volume control, because it's analog noise floor is so incredibly low.

The issues with digital volume control is mostly to do with unreliable math in 16 bit. Once we can be certain the math is good, then it comes down to avoiding pushing the analog volume control too hard.

I think anything between 70% and 100% volume on an Android phone that is using AptX HD, would be fine - just basically listen out for the analog noise floor. If you can hear any of it, turn the digital volume up and the analog down.

That's my take on it - this is great little device that get's so much of it right, with the right firmware, this thing is going to be highly sought after.

@PiSkyHiFi:

You're right.

Ideally, in digital domain,
16-bit provides 20 x log10(2^16) = 96 dB SNR,
24-bit provides 20 x log10(2^24) = 144 dB SNR.

If the system analog noise floor is around -110dB,
The 5-bit loss in the 24-bit source, 20 x 1og10(2^19) = 114dB, would still be OK.

For aptX-HD codec which is 24-bit,
a couple of steps of volume down from the maximum might be OK.

However, the others(e.g., SBC, AAC, aptX) are all 16-bit.
Thus the PCM truncation by volume control is done at 16-bit domain before the encoder.

Usually, Mobile phone volume slider provides 60 dB range in dB linear scale.
So you will get the bit loss as below:

100% volume ----> 0 dB FS / No bit loss
80% volume ----> -12 dB / 2-bit loss
60% volume ----> -24 dB / 4-bit loss

ES100 achieves the SNR around -109 ~ -110dB.
So, as you mentioned, 70% ~ 100% volume on aptX HD Android source would be fine,
because that loss in the digital domain is still below the ES100 system noise floor.
You exactly pointed out what I can expect assuming the performance of ES100.

But I believe there's one more thing to consider.
The Bluetooth codecs above are not lossless, but lossy.
If they are lossless, the digital volume down before and after the encoder would be exactly same.
But since they are all lossy,
the digital volume down before the encoder might cause more errors in the math of the codecs,
and would be considerably worse than expected.
That's my concern on that.

Again, thank you for your comment and have a nice weekend!

Regards,
WS

 

[PiSkyHiFi]

@PiSkyHiFi:

You're right.

Ideally, in digital domain,
16-bit provides 20 x log10(2^16) = 96 dB SNR,
24-bit provides 20 x log10(2^24) = 144 dB SNR.

If the system analog noise floor is around -110dB,
The 5-bit loss in the 24-bit source, 20 x 1og10(2^19) = 114dB, would still be OK.

For aptX-HD codec which is 24-bit,
a couple of steps of volume down from the maximum might be OK.

However, the others(e.g., SBC, AAC, aptX) are all 16-bit.
Thus the PCM truncation by volume control is done at 16-bit domain before the encoder.

Usually, Mobile phone volume slider provides 60 dB range in dB linear scale.
So you will get the bit loss as below:

0% volume ----> 0 dB FS / No bit loss
80% volume ----> -12 dB / 2-bit loss
60% volume ----> -24 dB / 4-bit loss

ES100 achieves the SNR around -109 ~ -110dB.
So, as you mentioned, 70% ~ 100% volume on aptX HD Android source would be fine,
because that loss in the digital domain is still below the ES100 system noise floor.
You exactly pointed out what I can expect assuming the performance of ES100.

But I believe there's one more thing to consider.
The Bluetooth codecs above are not lossless, but lossy.
If they are lossless, the digital volume down before and after the encoder would be exactly same.
But since they are all lossy,
the digital volume down before the encoder might cause more errors in the math of the codecs,
and would be considerably worse than expected.
That's my concern on that.

Again, thank you for your comment and have a nice weekend!

Regards,
WS

I agree with your analysis there. Your point about the codecs being not lossless is right.

Mathematically, when adjusting the volume of a digital signal, truncation is the worst algorithm. By first upscaling to 24 bit or higher or using a floating point internal path and appropriate dithering when reducing to the target dynamic range, the signal integrity is maintained well, I don't know what Android's algorithm is though, so you might still be right in this scenario.

Realistically, 95% of my music is 44.1KHz 16 bit and with these files, even the lossy nature of the AptX HD in 24 bits should have minimal impact on the sound quality, including some digital volume control, I've been looking for a device like the ES100 for a while now. I think if it had digital out, I would have bought 3 of them, still a great device anyway.

You're right about the other codecs - I think you're right to recommend maximum volume prior to encoding for those.

Tiny digital errors are an issue, but I would say that the choice of a decent quality DAC is more important, which you have done well on this device.

If my ears had to choose between a device that supports higher bitrates or a device with a higher quality DAC, I would choose the DAC first.

Thanks for your responses!

 

[zolom]

I agree with your analysis there. Your point about the codecs being not lossless is right.

Mathematically, when adjusting the volume of a digital signal, truncation is the worst algorithm. By first upscaling to 24 bit or higher or using a floating point internal path and appropriate dithering when reducing to the target dynamic range, the signal integrity is maintained well, I don't know what Android's algorithm is though, so you might still be right in this scenario.

Realistically, 95% of my music is 44.1KHz 16 bit and with these files, even the lossy nature of the AptX HD in 24 bits should have minimal impact on the sound quality, including some digital volume control, I've been looking for a device like the ES100 for a while now. I think if it had digital out, I would have bought 3 of them, still a great device anyway.

You're right about the other codecs - I think you're right to recommend maximum volume prior to encoding for those.

Tiny digital errors are an issue, but I would say that the choice of a decent quality DAC is more important, which you have done well on this device.

If my ears had to choose between a device that supports higher bitrates or a device with a higher quality DAC, I would choose the DAC first.

Thanks for your responses!

Waitng to use theh ES100 with Tidal, connected via UAPP, playing 16 bit HiFi, especially 24 bit MQA.
I guess the UAPP Bit Perfect is only relevant for USB DACs, please correvt me if I am wrong.

 

[wslee]

Waitng to use theh ES100 with Tidal, connected via UAPP, playing 16 bit HiFi, especially 24 bit MQA.
I guess the UAPP Bit Perfect is only relevant for USB DACs, please correvt me if I am wrong.

MQA is a kind of unique encoding format which provides higher resolution audio at the very efficient data rate.

Take a look at the below figures first:

16-bit PCM -------> 20*log10(2^16) = 96dB
24-bit PCM -------> 20*log10(2^16) = 144dB
28-bit PCM -------> 20*log10(2^28) = 168dB

16-bit x 2ch @ 48KHz -------> 1.536 Mbps
24-bit x 2ch @ 48KHz -------> 2.304 Mbps
28-bit x 2ch @ 48KHz -------> 2.688 Mbps

In general, the main cause of dominant noise floor is not the digital source or DAC,
but the amplifier noise and system thermal noise.

So it seems that we can hardly make the audio system noise floor lower than -120dB.
That is the primary assumption of MQA.

Then, 16-bit/96dB is not enough,
and 24-bit/144dB is too much because the dominant system noise floor is around -120dB.

As described above, encoding audio signal lower than -120dB is not practical and has no meaning.
So MQA encodes 0~24KHz baseband signal using only 20-bit to meet 120dB.
Then, the remains 4-bits are used for encoding the extended 24~48KHz signal.

Another assumption is that the dynamic range of high-frequency band is tiny.
So 4-bit is enough to encode high-frequency band.

(Actually, there are other details in deep-dive, and the bit allocation might differ from MQA source.
But just take a look at the big picture on that.)

Anyway, in that way, MQA can encode high-resolution audio at the effective data rate.

[Encoder]
24/96KHz High-Res source ---> MQA Encode ---> 24-bit x 2ch @ 48KHz packed 2.304 Mbps

[Decoder]
24-bit x 2ch @ 48KHz packed 2.304 Mbps ---> MQA Decode ---> 20-bit x 2ch @ 48KHz (BW:0~24KHz) + 4-bit x 2ch @ 96KHz (BW:24~48KHz)

Being cmapared to 96KHz 20-bit encoding, 20-bit x 2ch @ 96KHz / 3.840 Mbps,
MQA 24bit-2ch @ 48KHz / 2.304Mbps is still lower than the conventional PCM encoding,
while providing the same perceptual performance.

Furthermore, MQA is also designed for backward compatibility.
MQA encoded PCM can be played with generic PCM decoder.
The LSB 4-bit are processed same as generic PCM, but they are masked by the system noise floor and not audible.

On the other hand, if MQA decoder is there,
MQA expands bandwidth by 2x or 4x and provides high-resolution audio at the end.

In summary,
Both 24-bit PCM @ 96KHz and 24-bit MQA @ 48KHz perform just same.
I could say they are practically identical assuming -120dB system noise floor,
but the key is MQA works at the considerably lower bit rate.

Then, what we have to do to come up with MQA?
We need:
- lossless codecs like FLAC or WAV
- MQA decoder
- High-resolution audio system supporting at least 24-bit / 96KHz FS or higher

MQA stream can only be packed to the lossless codec, like FLAC or WAV.
All the MQA bits SHOULD be kept as the same.
And even if MQA decoder is running on the phone if mobile phone doesn't support 24/96KHz,
you may not be able to experience the high-resolution sound.

Again, MQA is the beautiful solution for the service provider like Tidal,
because they can save the bandwidth and their money while keeping the quality.

Lastly, I'm afraid you're not able to have ES100 or any other Bluetooth receiver keep up with the MQA quality.
The mobile phone may receive MQA stream from TIDAL and decode and expand it to 24/96KHz.
But before sending it over Bluetooth, the audio backend DSP on the phone will resample it to 48KHz/16(or 24).

Hope this helps you.

Thanks and Regards,
WS

p.s.

Currently, LDAC is the only Bluetooth codec supporting resolution above 24/48KHz.
If the mobile phone supports both MQA decoder and LDAC,
it's possible to have high-resolution MQA stream over Bluetooth.

[Mobile]
MQA source ---> MQA decoder ---> 24/96KHz ----> LDAC encoder ----> A2DP

[Receiver]
A2DP ---> LDAC Decoder ----> 24/96KHz

*However, LDAC high-resolution codec only works with a certain level of good RF environment.

 

[kolbo]

Any news on when it will be possible to order these?

 

[wslee]

I not meant volume sync.
I meant:
When the user enables the option and something is streamed to the es100 then your android or iphone app (also when running in the background) sets the source volume to 0db . And if it gets lowered it just sets the sourcevoulme back to 0db.
So the user can't accidentally lower the source volume on the device and has to control it via the es100 or the analog volume slider.

@meinname123:

What a nice suggestion!
I've just discussed with our team on your suggestion.

It might be possible, only in case, the user launches the ES100 mobile app;
technically we can forcibly set the source volume at the maximum and compensate the current target level with analog volume down.

If any volume change with the mobile phone with its side buttons occurs,
the app can detects the volume change notification and reset the volume to the maximum again, and set analog volume remotely.

Let say it's Smart Volume Control.

Let me research what you suggested deep-dive, and check the feasibility.
And we'll have an internal beta test if it's practical or not.
(Just concern that too many features will confuse some users.)

Anyway, thanks for your suggestion again and I'll check it right away.

Thanks and Regards,
WS

 

[tim0chan]

@meinname123:

What a nice suggestion!
I've just discussed with our team on your suggestion.

It might be possible, only in case, the user launches the ES100 mobile app;
technically we can forcibly set the source volume at the maximum and compensate the current target level with analog volume down.

If any volume change with the mobile phone with its side buttons occurs,
the app can detects the volume change notification and reset the volume to the maximum again, and set analog volume remotely.

Let say it's Smart Volume Control.

Let me research what you suggested deep-dive, and check the feasibility.
And we'll have an internal beta test if it's practical or not.
(Just concern that too many features will confuse some users.)

Anyway, thanks for your suggestion again and I'll check it right away.

Thanks and Regards,
WS

When will the product be released to mass market?

 

[Raketen]

Some other things I am curious about: Does the DSP/EQ processing default to flat when using without the app (for instance if I were using it with my PC)? Can it remember App DSP/EQ settings when paired to devices without the app?

 

[wslee]

Some other things I am curious about: Does the DSP/EQ processing default to flat when using without the app (for instance if I were using it with my PC)? Can it remember App DSP/EQ settings when paired to devices without the app?

@Raketen:

ES100 stores and keeps all the user configurations including the EQ setting, in the built-in Flash memory.
ES100 loads and applies EQ and every other user option immediately, right after boot-up.

That means once you set the EQ, you don't need to launch and check ES100 mobile application anymore.

The mobile application, when launched,
just reads the configurations stored in ES100 over Bluetooth,
and display them so that you can check the current status and maintain any further adjustment.

Every audio option including DCT, EQ and DAC filter is applied equally both in Bluetooth mode and in USB DAC mode.

Hope this answers you.

Thanks and Regards,
WS

 

[Raketen]

@Raketen:

ES100 stores and keeps all the user configurations including the EQ setting, in the built-in Flash memory.
ES100 loads and applies EQ and every other user option immediately, right after boot-up.

That means once you set the EQ, you don't need to launch and check ES100 mobile application anymore.

The mobile application, when launched,
just reads the configurations stored in ES100 over Bluetooth,
and display them so that you can check the current status and maintain any further adjustment.

Every audio option including DCT, EQ and DAC filter is applied equally both in Bluetooth mode and in USB DAC mode.

Hope this answers you.

Thanks and Regards,
WS

Very cool functionality. Thank you for the answer.

 

[tim0chan]

@Raketen:

ES100 stores and keeps all the user configurations including the EQ setting, in the built-in Flash memory.
ES100 loads and applies EQ and every other user option immediately, right after boot-up.

That means once you set the EQ, you don't need to launch and check ES100 mobile application anymore.

The mobile application, when launched,
just reads the configurations stored in ES100 over Bluetooth,
and display them so that you can check the current status and maintain any further adjustment.

Every audio option including DCT, EQ and DAC filter is applied equally both in Bluetooth mode and in USB DAC mode.

Hope this answers you.

Thanks and Regards,
WS

When will it be released to mass market? I really want one but cannot buy

 

[wslee]

How about adding a option for the end user to pay for the function, if they need/want it?
Pay, and unlock the extra feature via F/W update.

@Cane:

I'm sorry, but I don't think SONY would agree on that kind of license policy.
The Per Unit License is managed based on Bluetooth MAC address range.
Technically, it's possible, but SONY won't agree on that.
That means we have to buy all the copies of the license for full consecutive Bluetooth address range at a time.

We're continuous tracking the market's need.
LDAC is a good option but for high-resolution streaming above 24/48KHz, which aptX-HD provides,
requires a certain level of good enough RF environment.
Unless otherwise, it will limit the streaming bandwidth, just providing standard quality.

As long as LDAC is getting popular, we'll definitely add LDAC option in the future.

Thanks and Regards,
WS

 

[meinname123]

Let say it's Smart Volume Control.