MQN

Anything to do with computer audio, hardware, software etc.
janh
Posts: 88
Joined: Wed Oct 30, 2013 9:24 pm

Re: MQN

Post by janh »

I have listened to Mqnplay ldn v10, v12(with the message) and v13
Short: v12 > v13 > v10.
I am just an ordinary listener with too little live concert experience, so just take my word.

- String orchestra - v10 sound more closed (bit more distant) than v13 which is more open, clear, very fine. not much diff. to v12.
- violin sonata much the same.
- Voice (soprano) with piano - v10 voice is less clear, almost some artefacts on it. v13 much better, more clarity. v12 even better, still more clarity and feel of the voice.
- piano - v13 fine, but v12 better. like in v13 the notes have longer decay which give a halo. v12 very clear and fine feeling of piano acoustics.
Gigabyte H97M-D3H with PPA OCXO module. i7-4790T, 800MHz. 8GB Ram, 800MHz.
PPA 2-rail LPSU & Pico. JCAT battery for OS-SSD and PPA v3 USBcard.
Server 2012 R2, AO 1.40. APL HiFi DAC-S, upd. Only use 1644 .wav
sbgk
Posts: 1950
Joined: Mon Oct 07, 2013 9:45 pm

Re: MQN

Post by sbgk »

uploaded v14 - haswell only, does sound good.
sbgk
Posts: 1950
Joined: Mon Oct 07, 2013 9:45 pm

Re: MQN

Post by sbgk »

I asked about whether the regen is still affected by the player software and the reply was that the hub chip still allows noise through which can't be stopped by reclocking, so it does still get affected by the player/upstream processes.

Whether this is the case or there is something else going on eg noise being captured in the wav data in some way. The regen was developed by hardware guys so taking software effects into consideration is not their forte.
janh
Posts: 88
Joined: Wed Oct 30, 2013 9:24 pm

Re: MQN

Post by janh »

I have listened to mqnplay ldn v12, v13 and v14.
short: v14 > v12 > v13

v14 has overall more clearity.
- On piano now v12 has the halo, I like the clearer sound of v14 very much, maybe those who know piano sound more should tell.
- The soprano voice of v14 is a joy, there is more clearity and also a purity and life in the voice.
- A large choir - a difficult hifi-discipline I would think - is better. v14 definitely is more clear in voices and acoustic, although here still a lot more is possible.
- Orchestra (dense orch. sound, mostly strings) - v14 is noticeably better both in violins and bass.

To me v14 is a winner!! Congratulations sbgk.
Would love to have this in "full production" form, not only as a test.

Jan H
Gigabyte H97M-D3H with PPA OCXO module. i7-4790T, 800MHz. 8GB Ram, 800MHz.
PPA 2-rail LPSU & Pico. JCAT battery for OS-SSD and PPA v3 USBcard.
Server 2012 R2, AO 1.40. APL HiFi DAC-S, upd. Only use 1644 .wav
jkeny
Posts: 2387
Joined: Sun Jan 17, 2010 9:37 pm

Re: MQN

Post by jkeny »

sbgk wrote:I asked about whether the regen is still affected by the player software and the reply was that the hub chip still allows noise through which can't be stopped by reclocking, so it does still get affected by the player/upstream processes.

Whether this is the case or there is something else going on eg noise being captured in the wav data in some way. The regen was developed by hardware guys so taking software effects into consideration is not their forte.
Gordon, what John Swenson is saying is that the quality of the USB signal will cause noise in the USB receiver as the lower the quality, the harder the USB receiver works to decode the cock & the data from the signal. As a result noise will be generated by this extra processing load (as a result of increased current draw) on the PS of the receiving device. If this receiving device is a USB DAC this noise can directly contaminate the sensitive devices in the DAC i.e clocks & DAC chip itself.

I suspect that it is the fluctuation in signal integrity & as a result fluctuation in noise that is the problem. If it was constant I doubt it would be an issue

So there are a number of ways to attack this issue (& they can all be complimentary):
1) Treatments at the front end i.e PC
- Minimise the noise (fluctuations) at the PC end by the use of individual, isolated PSes powering different crucial parts of the PC ala Nige.
- Using software which minimises this noise fluctuation. Transfer of data between devices (HDD, RAM, etc) inside the PC would seem to be an area which might result in fluctuations in current draws & hence in PS noise.

So far, it seems that a perfectly formed USB signal has not been achievable by these methods (based on the fact that as we keep finding another improvement, either in PS or in software). It may not be possible to find the improvement plateau here due to the nature of both the PC & the USB protocol itself?

So we may have to accept that with current general purpose computer hardware & OS & USB protocol we can't completely solve the signal integrity issue to the point where there is no more improvement to be achieved.

Even if we had a perfect USB signal, transmitting such a high speed signal over a USB cable undoubtedly results in some degradation of the signal integrity (SI).

2) Treatments at the receiving end i.e USB DAC
- trying to decouple from the DAC, the noise that is created by the less than perfect USB signal.

This is what the Regen is attempting - it's designed to be connected at the USB input to the USB DAC & it receives the USB signal first before passing on a cleaned up, regenerated version of the USB signal directly into the DAC's USB port.
The USB receiver in the Regen generates the same noise in trying to extract the clock & data from the USB signal but this noise is on the PS that powers the Regen, not the PS that powers the DAC so there is some amount of isolation afforded
There are also other possible reasons for it's reported improvements in SQ - the use of a good 24MHz USB clock in the Regen could be part of it? The adherence to strict 90ohm impedance between Regen & DAC, another.

All will be teased out in time, hopefully?
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
sbgk
Posts: 1950
Joined: Mon Oct 07, 2013 9:45 pm

Re: MQN

Post by sbgk »

Thanks John, informative stuff.

how does the device know it's dealing with a poor usb signal ?

We are all suffering from the design decisions made by designers/engineers who thought bits are bits.
sbgk
Posts: 1950
Joined: Mon Oct 07, 2013 9:45 pm

Re: MQN

Post by sbgk »

janh wrote:I have listened to mqnplay ldn v12, v13 and v14.
short: v14 > v12 > v13

v14 has overall more clearity.
- On piano now v12 has the halo, I like the clearer sound of v14 very much, maybe those who know piano sound more should tell.
- The soprano voice of v14 is a joy, there is more clearity and also a purity and life in the voice.
- A large choir - a difficult hifi-discipline I would think - is better. v14 definitely is more clear in voices and acoustic, although here still a lot more is possible.
- Orchestra (dense orch. sound, mostly strings) - v14 is noticeably better both in violins and bass.

To me v14 is a winner!! Congratulations sbgk.
Would love to have this in "full production" form, not only as a test.

Jan H
that's what I think as well.

uploaded v15, hopefully last tweek for a while. wonder what you think of it ? Adds a real shine to piano, don't know if thats better.

yup, think that's the winner, tremendous live feel and excitement to the music.

Aleg not trying these ones ? They should work as they use the standard method.
nige2000
Posts: 4253
Joined: Thu Feb 14, 2013 10:47 am
Location: meath

Re: MQN

Post by nige2000 »

jkeny wrote:
sbgk wrote:I asked about whether the regen is still affected by the player software and the reply was that the hub chip still allows noise through which can't be stopped by reclocking, so it does still get affected by the player/upstream processes.

Whether this is the case or there is something else going on eg noise being captured in the wav data in some way. The regen was developed by hardware guys so taking software effects into consideration is not their forte.
Gordon, what John Swenson is saying is that the quality of the USB signal will cause noise in the USB receiver as the lower the quality, the harder the USB receiver works to decode the cock & the data from the signal. As a result noise will be generated by this extra processing load (as a result of increased current draw) on the PS of the receiving device. If this receiving device is a USB DAC this noise can directly contaminate the sensitive devices in the DAC i.e clocks & DAC chip itself.

I suspect that it is the fluctuation in signal integrity & as a result fluctuation in noise that is the problem. If it was constant I doubt it would be an issue

So there are a number of ways to attack this issue (& they can all be complimentary):
1) Treatments at the front end i.e PC
- Minimise the noise (fluctuations) at the PC end by the use of individual, isolated PSes powering different crucial parts of the PC ala Nige.
- Using software which minimises this noise fluctuation. Transfer of data between devices (HDD, RAM, etc) inside the PC would seem to be an area which might result in fluctuations in current draws & hence in PS noise.

So far, it seems that a perfectly formed USB signal has not been achievable by these methods (based on the fact that as we keep finding another improvement, either in PS or in software). It may not be possible to find the improvement plateau here due to the nature of both the PC & the USB protocol itself?

So we may have to accept that with current general purpose computer hardware & OS & USB protocol we can't completely solve the signal integrity issue to the point where there is no more improvement to be achieved.

Even if we had a perfect USB signal, transmitting such a high speed signal over a USB cable undoubtedly results in some degradation of the signal integrity (SI).

2) Treatments at the receiving end i.e USB DAC
- trying to decouple from the DAC, the noise that is created by the less than perfect USB signal.

This is what the Regen is attempting - it's designed to be connected at the USB input to the USB DAC & it receives the USB signal first before passing on a cleaned up, regenerated version of the USB signal directly into the DAC's USB port.
The USB receiver in the Regen generates the same noise in trying to extract the clock & data from the USB signal but this noise is on the PS that powers the Regen, not the PS that powers the DAC so there is some amount of isolation afforded
There are also other possible reasons for it's reported improvements in SQ - the use of a good 24MHz USB clock in the Regen could be part of it? The adherence to strict 90ohm impedance between Regen & DAC, another.

All will be teased out in time, hopefully?
its rather discouraging that so much has to be modified on the pc side to provide a clean signal
and yet clear improvements still seem to come with further experimentation

ive never heard anything yet immune to upstream power/ clocking influences (sure some devices more affected than others)

with ians fifo reclocker there was still clearly differences in sq with different software, pc mods, usb cable and type of usb to i2s device along with latency settings

the regen isnt really anything new id doubt it would out perform a cleanly powered usb card

i wonder if the 1's are mean mistake'd for 0's because of an unclean signal

would be nice if we were able to design a very simple pc/player from scratch with what we learnt over the years
sd card player, modded soekris dac, class a lifepo4 amp or gb class a/b amp, diy open baffle speakers based on project audio mundorf trio 10's
Aleg
Posts: 1381
Joined: Thu Oct 10, 2013 8:26 pm

Re: MQN

Post by Aleg »

sbgk wrote:....

Aleg not trying these ones ? They should work as they use the standard method.

Just got home from the UK.
Didn't have time yet to listen.
Did check and noticed they do work now on my setup.

I do like what I hear on v15
HDPLEX;picoPSU;ASUS Q87M;i7-4770T;PH SR7EHD;Server2012R2;Thesycon 2.24;
JCAT USB;Sonicweld DiverterHR2;Naim DC1;Chord Hugo;Morrow Audio MA6;Naim NAC-282,SuperCapDR;NAP-300;
AQ Cinnamon;GISO GB;Netgear Pro+XM21X;Cisco SG300;NAS-ZFS.
sbgk
Posts: 1950
Joined: Mon Oct 07, 2013 9:45 pm

Re: MQN

Post by sbgk »

Aleg wrote:
sbgk wrote:....

Aleg not trying these ones ? They should work as they use the standard method.

Just got home from the UK.
Didn't have time yet to listen.
Did check and noticed they do work now on my setup.

I do like what I hear on v15
that really is the best I can do without hacking drivers etc.

next step would be linux with modified kernel and drivers, that's a long term goal.

so now to make it functional.
Post Reply