Jump to content
IGNORED

TEAC NT-505 NT505 Worth Waiting for ?


Recommended Posts

7 hours ago, wklie said:

Meaning of the various Bulk Pet modes:

 

https://translate.google.com/translate?hl=en&sl=ja&tl=en&u=http%3A%2F%2Fwww.oliospec.com%2Fblog%2F%3Fp%3D1582

 

s-Blukpet09-2.jpg

 

Note: FYI only, I'm not affiliated with this USB stuff.

This is nonsense. The USB spec doesn't support what they claim to be doing. Some basic facts about USB:

  • The data rate is fixed at 480 Mbps
  • A microframe starts every 125 μs

  • A microframe can transfer up to about 6 kB of data in one or more transactions

Suppose we are playing stereo 24-bit 96 kHz audio. The data rate of this format is 576 kB/s or 72 bytes per microframe. The host controller may choose to split these 72 bytes across multiple transactions, but it probably won't. Software cannot influence this. All this is true for both bulk and isochronous modes.

 

In isochronous mode, the host controller is guaranteed to send one data chunk every microframe providing a guaranteed bandwidth with fixed latency. In contrast, bulk mode lets the controller allocate a transfer within and across microframes however it sees fit. There are no guarantees of either bandwidth or latency.

 

"Bulk Pet" allegedly creates a smooth flow of data. From the software side, including OS drivers, the only way to do anything of the kind in bulk mode is to issue a small (72 bytes in our example) transaction every 125 μs and hope the host controller sends it immediately. This would create a huge processing overhead and also impose impossible timing requirements on the OS. In other words, it is a Very Bad Idea™. Even if this could somehow be pulled off, you'd still be sending those 72 bytes per microframe at the fixed rate of 480 Mbps, or in other words, there will be brief bursts of bus activity between longer idle periods.

 

This is how USB works at the hardware level. Nothing software can do will change this.

Link to comment
2 hours ago, mansr said:

This is nonsense. The USB spec doesn't support what they claim to be doing. Some basic facts about USB:

  • The data rate is fixed at 480 Mbps
  • A microframe starts every 125 μs

  • A microframe can transfer up to about 6 kB of data in one or more transactions

Suppose we are playing stereo 24-bit 96 kHz audio. The data rate of this format is 576 kB/s or 72 bytes per microframe. The host controller may choose to split these 72 bytes across multiple transactions, but it probably won't. Software cannot influence this. All this is true for both bulk and isochronous modes.

 

In isochronous mode, the host controller is guaranteed to send one data chunk every microframe providing a guaranteed bandwidth with fixed latency. In contrast, bulk mode lets the controller allocate a transfer within and across microframes however it sees fit. There are no guarantees of either bandwidth or latency.

 

"Bulk Pet" allegedly creates a smooth flow of data. From the software side, including OS drivers, the only way to do anything of the kind in bulk mode is to issue a small (72 bytes in our example) transaction every 125 μs and hope the host controller sends it immediately. This would create a huge processing overhead and also impose impossible timing requirements on the OS. In other words, it is a Very Bad Idea™. Even if this could somehow be pulled off, you'd still be sending those 72 bytes per microframe at the fixed rate of 480 Mbps, or in other words, there will be brief bursts of bus activity between longer idle periods.

 

This is how USB works at the hardware level. Nothing software can do will change this.

 

I wonder if someone who owns one of these could have a look at CPU utilization when using the different transmission settings to show an increase with the "smoothest" transmission mode.

 

I'm actually tempted to upgrade my TEAC UD-501 (just because). If I do, I'll even give this a try myself...

 

 

Archimago's Musings: A "more objective" take for the Rational Audiophile.

Beyond mere fidelity, into immersion and realism.

:nomqa: R.I.P. MQA 2014-2023: Hyped product thanks to uneducated, uncritical advocates & captured press.

 

 

Link to comment
20 minutes ago, Archimago said:

I'm actually tempted to upgrade my TEAC UD-501 (just because). If I do, I'll even give this a try myself...

 

I guess you may also be interested in the Low-dispersion Short Delay filter, which is a new feature of AK4497.

Peter Lie

LUMIN Firmware Lead

Link to comment
18 minutes ago, wklie said:

 

I guess you may also be interested in the Low-dispersion Short Delay filter, which is a new feature of AK4497.

 

Yeah, plus just seeing how the AK4497 performs... Also to see how the MQA decode works with something that's not based on ESS DAC chipset. aptX and LDAC output also.

 

Hmmm, is MQA only for the NT-505???

 

 

Archimago's Musings: A "more objective" take for the Rational Audiophile.

Beyond mere fidelity, into immersion and realism.

:nomqa: R.I.P. MQA 2014-2023: Hyped product thanks to uneducated, uncritical advocates & captured press.

 

 

Link to comment
42 minutes ago, Archimago said:

I wonder if someone who owns one of these could have a look at CPU utilization when using the different transmission settings to show an increase with the "smoothest" transmission mode.

 

I'm actually tempted to upgrade my TEAC UD-501 (just because). If I do, I'll even give this a try myself...

I'd like to see a capture of the USB traffic.

Link to comment
8 minutes ago, mansr said:

I'd like to see a capture of the USB traffic.

 

Yup. That would tell all... Although it would be nice to know what kind of performance hit this transmission mode impacts on the computer.

 

7 minutes ago, mansr said:

Sounds like another name for linear phase slow roll-off.

 

Yeah. Although they have a "Slow Roll-off" and "Super slow roll-off" as well which could be minimum phase.

 

Funny how they have all these names instead of just saying what it is...

 

 

Archimago's Musings: A "more objective" take for the Rational Audiophile.

Beyond mere fidelity, into immersion and realism.

:nomqa: R.I.P. MQA 2014-2023: Hyped product thanks to uneducated, uncritical advocates & captured press.

 

 

Link to comment

Yuck. I just wish designers would get out of the way of the signal.

 

Call me a retro minimalist grouch, but less $ on gimmick bells & whistles, give me a decent chipset (seems easy these days) with the best possible power supply and analog output within budget, please.  What's so hard about that? Oh yeah, marketing.

 

It's disappointing, TEAC seemed to be on the right track with the dual mono thing.  I really like my UD-503 for the $ (tho I disable all the on-board upsampling).

 

 

Link to comment
1 hour ago, Archimago said:

 

Yeah, plus just seeing how the AK4497 performs... Also to see how the MQA decode works with something that's not based on ESS DAC chipset. aptX and LDAC output also.

 

Hmmm, is MQA only for the NT-505???

 

The EU spec sheet shows MQA for the NT-505 but not the UD-505.

Link to comment
10 hours ago, Archimago said:

is MQA only for the NT-505???

 

Yes, because the MQA decoder should run on the NT-505 network module (which supports native Tidal Masters), it can be used for network input and music file from USB storage only.  Other inputs do not go through the MQA decoder.

 

Currently available NT-505 units in Asia do not support MQA or Roon Ready yet - these are meant to be enabled in future firmware upgrade.

Peter Lie

LUMIN Firmware Lead

Link to comment
1 hour ago, wklie said:

 

Yes, because the MQA decoder should run on the NT-505 network module (which supports native Tidal Masters), it can be used for network input and music file from USB storage only.  Other inputs do not go through the MQA decoder.

 

Currently available NT-505 units in Asia do not support MQA or Roon Ready yet - these are meant to be enabled in future firmware upgrade.

 

Okay. Guess I'll keep my eyes open for when the NT-505 is available here in Canada.

 

 

Archimago's Musings: A "more objective" take for the Rational Audiophile.

Beyond mere fidelity, into immersion and realism.

:nomqa: R.I.P. MQA 2014-2023: Hyped product thanks to uneducated, uncritical advocates & captured press.

 

 

Link to comment
2 hours ago, wklie said:

 

Yes, because the MQA decoder should run on the NT-505 network module (which supports native Tidal Masters), it can be used for network input and music file from USB storage only.  Other inputs do not go through the MQA decoder.

 

Currently available NT-505 units in Asia do not support MQA or Roon Ready yet - these are meant to be enabled in future firmware upgrade.

 

Oh interesting. So if you stream TIdal Masters to the USB input of the NT-505, it will not do MQA decoding?

Link to comment

Tidal desktop app and Audirvana (and Roon with the future MQA upgrade) should decode MQA to MQA Core (first unfold) and send it to NT/UD-505 USB input.

 

Full MQA decode should become available for NT-505 native Tidal or music files from NAS or USB storage, when the firmware is upgraded in the future.

 

I think this is similar to Esoteric N-01 and PS Audio Bridge II.  Pro-Ject S2 decodes MQA from USB input but not from SPDIF input.

Peter Lie

LUMIN Firmware Lead

Link to comment
22 hours ago, Acesn8s said:

The EU spec sheet shows MQA for the NT-505 but not the UD-505.

 

The specs for the UD-505 say:

 

""Bulk Pet" USB transfer technology, with four transfer modes to vary sound character...."

 

I thought maybe @mansr initial reaction was too strong, but why would USB delivery "vary sound character"??  That is, other than the usual Audiophile marketing voodoo nonsense...

Hey MQA, if it is not all $voodoo$, show us the math!

Link to comment
7 minutes ago, crenca said:

The specs for the UD-505 say:

 

""Bulk Pet" USB transfer technology, with four transfer modes to vary sound character...."

 

I thought maybe @mansr initial reaction was too strong, but why would USB delivery "vary sound character"??  That is, other than the usual Audiophile marketing voodoo nonsense...

It's worse than that. Their "transfer modes" aren't possible, even if they did vary the sound character. Read the USB spec if you don't believe me.

Link to comment
10 hours ago, wklie said:

FYI: The link in @seeteeyou post above contains listening impressions of this (but for a different device).  Here's a google translation:

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fkotonohanoana.com%2Farchives%2F17503&edit-text=&act=url

Such reports are worthless. If there's a setting that can be changed, people will "hear" differences. The Audirvana player offers a few filter choices for DSD upsampling. For a while at least, two of them were actually exactly the same filter. Nonetheless, people reported hearing clear differences between them.

Link to comment
  • 3 weeks later...
On 2/28/2018 at 3:20 PM, mansr said:

In isochronous mode, the host controller is guaranteed to send one data chunk every microframe providing a guaranteed bandwidth with fixed latency. In contrast, bulk mode lets the controller allocate a transfer within and across microframes however it sees fit. There are no guarantees of either bandwidth or latency.

 

There have been audio devices that use bulk-mode on the market already. For example I think first one on audiophile market was M2Tech hiFace (driver is in Linux kernel if you are curious). Then later for example Mytek Stereo192-DSD DAC using different implementation. And third implementation AFAIK is exaSound's.

 

What you can gain compared to UAC is flexibility, simplicity and reliability (error correction). On UAC, 48k-base rates have always been more natural for the protocol than 44.1k-base ones which are much less "in-sync". The isochronous asynchronous UAC is quite a beast with bunch of curious implementation details.

 

Those earlier implementations were just never marketed the way TEAC is now doing - no comments on that. What is new with the implementation used in TEAC seems to be capability to support both UAC and proprietary bulk-mode transfer in the same implementation.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
1 hour ago, Miska said:

What you can gain compared to UAC is flexibility, simplicity and reliability (error correction). On UAC, 48k-base rates have always been more natural for the protocol than 44.1k-base ones which are much less "in-sync". The isochronous asynchronous UAC is quite a beast with bunch of curious implementation details.

1) It is not a problem that some packets contain one sample more than others. Besides, the slightest difference between the host and device clocks will have this result even for 48 kHz base rates. That's the entire damn point.

2) Bulk mode uses the same 125 μs microframe interval, so the variation in sample count still occurs. And still isn't a problem.

 

Bulk mode does have error correction, however at the expense of unbounded latency and no guaranteed throughput. In reality, errors are rare enough that isochronous mode works just fine.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...