IPB

Welcome Guest ( Log In | Register )

> Hydrogenaudio Forum Rules

- No Warez. This includes warez links, cracks and/or requests for help in getting illegal software or copyrighted music tracks!
- No Spamming or Trolling on the boards, this includes useless posts, trying to only increase post count or trying to deliberately create a flame war.
- No Hateful or Disrespectful posts. This includes: bashing, name-calling or insults directed at a board member.
- Click here for complete Hydrogenaudio Terms of Service

2 Pages V   1 2 >  
Reply to this topicStart new topic
RAM access speed tests with a few players, Offtopic - has nothing to do with audio performance
JimH
post Feb 14 2012, 16:14
Post #1





Group: Members
Posts: 148
Joined: 14-July 02
From: Minneapolis
Member No.: 2588



We recently tested a few software players on Windows to see how fast they could access RAM. Some player makers claim it matters. We don't think so. But the results were interesting.

http://wiki.jriver.com/index.php/Audio_Testing
Go to the top of the page
+Quote Post
probedb
post Feb 14 2012, 16:40
Post #2





Group: Members
Posts: 1194
Joined: 6-September 04
Member No.: 16817



QUOTE (JimH @ Feb 14 2012, 15:14) *
We recently tested a few software players on Windows to see how fast they could access RAM. Some player makers claim it matters. We don't think so. But the results were interesting.

http://wiki.jriver.com/index.php/Audio_Testing


How did you test this? You make no mention of that in the article or here.
Go to the top of the page
+Quote Post
JimH
post Feb 14 2012, 17:16
Post #3





Group: Members
Posts: 148
Joined: 14-July 02
From: Minneapolis
Member No.: 2588



QUOTE (probedb @ Feb 14 2012, 09:40) *
How did you test this? You make no mention of that in the article or here.

Sorry. It was a special ASIO driver. We've modified the wiki topic to add more detail. Here's what it says:

"It's easy to measure how fast different players are at this. This is done by compiling an ASIO driver that includes instrumented timing of its calls back to to the player for data (the ASIO call bufferSwitchTimeInfo).

"The tests below time the average buffer fill performance during the course of a five minute song. The test machine is an i7 running Windows 7 x64.

"Here is how several players stack up in this regard, testing ASIO output as 32-bit integer (a common hardware format)"
Go to the top of the page
+Quote Post
Batman321
post Feb 14 2012, 18:53
Post #4





Group: Members
Posts: 64
Joined: 28-December 09
Member No.: 76405



What about Winamp?
Go to the top of the page
+Quote Post
monkey
post Feb 14 2012, 19:30
Post #5


Monkey's Audio developer


Group: Developer
Posts: 11
Joined: 15-October 01
Member No.: 298



QUOTE (Batman321 @ Feb 14 2012, 17:53) *
What about Winamp?


Media Monkey uses this Winamp plugin:
http://otachan.com/out_asio(dll).html

So I would expect Winamp to benchmark the same as Media Monkey.
Go to the top of the page
+Quote Post
Arnold B. Kruege...
post Feb 14 2012, 19:30
Post #6





Group: Members
Posts: 3647
Joined: 29-October 08
From: USA, 48236
Member No.: 61311



QUOTE (JimH @ Feb 14 2012, 10:14) *
We recently tested a few software players on Windows to see how fast they could access RAM. Some player makers claim it matters. We don't think so. But the results were interesting.

http://wiki.jriver.com/index.php/Audio_Testing



Let us see, the maximum number of samples per microsecond of 192 KHz sampling is 0.2, right? Seems like you would need a ton of channels to tax any of the players you tested, right?
Go to the top of the page
+Quote Post
JimH
post Feb 14 2012, 19:53
Post #7





Group: Members
Posts: 148
Joined: 14-July 02
From: Minneapolis
Member No.: 2588



Here's another memory related test we did this week:
http://www.computeraudiophile.com/content/...st-audio-player

and a listening test of JRiver vs jplay:
http://yabb.jriver.com/interact/index.php?topic=70043.0

All of the testing was part of our response to the questionable claims jplay has made about their software.
Go to the top of the page
+Quote Post
monkey
post Feb 14 2012, 20:13
Post #8


Monkey's Audio developer


Group: Developer
Posts: 11
Joined: 15-October 01
Member No.: 298



In this thread, memory movement performance was also discussed:
http://www.computeraudiophile.com/content/...gement-be-heard

The author of HQPlayer made condescending remarks about the use of memcpy(...) to fill sound card buffers.

The author claimed to write hand-tuned assembly that was twice as fast.

HQPlayer performed at the bottom of the performance test:
http://wiki.jriver.com/index.php/Audio_Testing

This post has been edited by monkey: Feb 14 2012, 20:15
Go to the top of the page
+Quote Post
JJZolx
post Feb 14 2012, 20:39
Post #9





Group: Members
Posts: 395
Joined: 26-November 04
Member No.: 18345



Apparently you can have your cake and eat it too. He claims to not believe that faster processing makes a difference, then goes on to show that JRiver performance is superior. I guess that appeases those on both sides.

QUOTE
JRiver believes all modern computers are fast enough at #2, and that more speed is not relevant. But some companies make claims to the contrary, so let's test performance.


QUOTE
Samples per Ás (higher is better)


CODE
Results

Player              Samples per Ás (higher is better)
JRiver                  1019.2
MediaMonkey             1013.8
cPlay                    864.0
Foobar2000               364.9
HQPlayer                 167.4
JPlay                  No ASIO
XXHighEnd              No ASIO


This post has been edited by JJZolx: Feb 14 2012, 20:39
Go to the top of the page
+Quote Post
saratoga
post Feb 14 2012, 20:47
Post #10





Group: Members
Posts: 4853
Joined: 2-September 02
Member No.: 3264



QUOTE (monkey @ Feb 14 2012, 14:13) *
In this thread, memory movement performance was also discussed:
http://www.computeraudiophile.com/content/...gement-be-heard

The author of HQPlayer made condescending remarks about the use of memcpy(...) to fill sound card buffers.

The author claimed to write hand-tuned assembly that was twice as fast.


I like how when people point out how stupid that is, he refuses to say what he measured or how he did it and instead links the Intel reference manual. Because I guess he wants to make it known that hes aware that the Intel manual exists.

Go to the top of the page
+Quote Post
Porcus
post Feb 14 2012, 20:53
Post #11





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE
(higher is better)


Yeah, JimH is unawaringly falling for the competition's marketing nonsense. He.Will.Be.Assimilated.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
monkey
post Feb 14 2012, 21:03
Post #12


Monkey's Audio developer


Group: Developer
Posts: 11
Joined: 15-October 01
Member No.: 298



QUOTE (Arnold B. Krueger @ Feb 14 2012, 18:30) *
Let us see, the maximum number of samples per microsecond of 192 KHz sampling is 0.2, right? Seems like you would need a ton of channels to tax any of the players you tested, right?



All players are fast enough on a modern machine.

I suppose you could imagine a scenario where a slower machine might encounter a buffer shortfall, which would play as a stutter or silence, under system load in one player but not another player.

However, this type of thing is obvious and normally fixed by using a larger hardware buffer.

To be clear, we're not claiming this performance matters to sound quality. The competitors are claiming it matters.

So we're trying to give the claims a fair technical testing and see how they hold up.
Go to the top of the page
+Quote Post
JimH
post Feb 14 2012, 21:25
Post #13





Group: Members
Posts: 148
Joined: 14-July 02
From: Minneapolis
Member No.: 2588



QUOTE (Porcus @ Feb 14 2012, 13:53) *
QUOTE
(higher is better)


Yeah, JimH is unawaringly falling for the competition's marketing nonsense. He.Will.Be.Assimilated.

That should have said "higher is faster". We've also said that faster doesn't matter, doesn't produce better sound quality.
Go to the top of the page
+Quote Post
spoon
post Feb 14 2012, 23:00
Post #14


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2741
Joined: 24-March 02
Member No.: 1615



Someone needs to convince me this is not a totally flawed test (comparing apples and oranges), I am thinking you are testing players which pre-buffer the whole track (so there is a large HDD / CPU hit at the start of the track) and compare to other players which read in realtime (HDD / CPU hit is spread out over the length of the track)...


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Kohlrabi
post Feb 14 2012, 23:28
Post #15





Group: Super Moderator
Posts: 1004
Joined: 12-March 05
From: Kiel, Germany
Member No.: 20561



Can someone explain to me why this matters at all? As long as you get no stutters during playback/the buffer fills up nicely I see no problem with access speeds. Even the thought of assuming the speed of loading samples to RAM having an impact on playback fidelity absolutely dumbfounds me. Just because no tests exist doesn't mean that testing something like this makes any sense. I don't see the point in testing unfounded claims by "audiophiles" to prove them wrong, it is their responsibility to prove that they're right.

This post has been edited by Kohlrabi: Feb 14 2012, 23:33


--------------------
Audiophiles live in constant fear of jitter.
Go to the top of the page
+Quote Post
monkey
post Feb 14 2012, 23:30
Post #16


Monkey's Audio developer


Group: Developer
Posts: 11
Joined: 15-October 01
Member No.: 298



QUOTE (spoon @ Feb 14 2012, 22:00) *
Someone needs to convince me this is not a totally flawed test (comparing apples and oranges), I am thinking you are testing players which pre-buffer the whole track (so there is a large HDD / CPU hit at the start of the track) and compare to other players which read in realtime (HDD / CPU hit is spread out over the length of the track)...


The test measures ASIO buffer fill performance, spread over real-time playback of a 5 minute song.

Pre-buffering is not particularly relevant to the speed with which device buffers are filled unless you were reading from disk in the ASIO fill callback, which I can't imagine anyone would do (certainly not JRiver or f2k).

Said another way, what happens in the reading threads, processing threads, system threads, loading before playing threads, etc. is not measured. The only measurement is where the rubber meets the road -- filling the device buffers.
Go to the top of the page
+Quote Post
JimH
post Feb 15 2012, 01:38
Post #17





Group: Members
Posts: 148
Joined: 14-July 02
From: Minneapolis
Member No.: 2588



QUOTE (Kohlrabi @ Feb 14 2012, 16:28) *
As long as you get no stutters during playback/the buffer fills up nicely I see no problem with access speeds.


I agree with you. I've described this as "just in time". Beyond that, any increase in the speed by which you fill RAM should not matter at all. But... there are some other software developers claiming otherwise. You could read a little here:

http://www.computeraudiophile.com/Forums/Equipment/Software
Go to the top of the page
+Quote Post
JimH
post Feb 15 2012, 14:07
Post #18





Group: Members
Posts: 148
Joined: 14-July 02
From: Minneapolis
Member No.: 2588



This was moved because it had "nothing to do with audio performance".

The tests were conducted because other players, principally jplay, were claiming that memory access speed did affect sound quality. Silly, I know, but true. Read a few of the posts at comuteraudiophile.com to learn more.

This forum demands data, and that's what was provided. I'm sorry you don't agree.
Go to the top of the page
+Quote Post
Kohlrabi
post Feb 15 2012, 14:58
Post #19





Group: Super Moderator
Posts: 1004
Joined: 12-March 05
From: Kiel, Germany
Member No.: 20561



JimH:

Reading the discussion at http://www.computeraudiophile.com/Forums/Equipment/Software, I still don't see the point in even investigating that matter. Just because you can create some data doesn't mean that they have any meaning at all. The only thing I see is that there is now an article on this on your wiki, which is prominently linked to HA, with statements like "Samples per Ás (higher is better)" and "JRiver still believes that speed doesn't matter." So you did not reach a conclusion about the effect on audio quality? The last sentence can be stated without even testing anything at all. Either you did prove that access speed does affect audio quality, or you didn't. Your data is not helpful in any way to prove or falsify that claim. So the only thing I see now is a wiki entry where JRiver achieved the highest number in some meaningless test, and statements about belief. Cynical people, like me, might see an angle there to attract the sort of crowd most people here at HA despise.

Of course you are free to do any tests and post them on your site, but I don't see how this warrants an HA discussion. Moreso since your test didn't provide any result regarding the claims. Does or does not RAM access affect playback quality?


EDIT: I can accept that this is pure advertising, if this thread stays in Off-Topic.

This post has been edited by Kohlrabi: Feb 15 2012, 15:14


--------------------
Audiophiles live in constant fear of jitter.
Go to the top of the page
+Quote Post
spoon
post Feb 15 2012, 15:50
Post #20


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2741
Joined: 24-March 02
Member No.: 1615



The issue at heart here is two fold:

1) HA becomes a battle ground for nonsense Audiofile claims, users who hear differences will popup, and HA will descend into trash...

2) Authors will clamber to embrace such nonsense, a modern system can transfer 16GB/second from memory, CD quality audio requires just 176KB, or 0.0001 GB/s - see the issue, everyone who writes a player will feel the need to get closer to a value which is meaningless. You know that it would be possible to better the values presented here?, but doing so would create a player which impacts the system, so suddenly all our favorite players will have this negative impact? a pointless arms race.

That is why such threads as this need to be removed from circulation, as it is not about free speech, this thread is as loaded as they come and full over overtones.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Peter
post Feb 15 2012, 15:56
Post #21


foobar2000 developer


Group: Admin
Posts: 3275
Joined: 30-September 01
Member No.: 84



Software players can be "optimized" to score "better" at such pseudobenchmarks, except it will hamper other functionality (say, out-of-process ASIO to cope with buggy drivers more nicely surely degrades the score here).
Go to the top of the page
+Quote Post
monkey
post Feb 15 2012, 16:27
Post #22


Monkey's Audio developer


Group: Developer
Posts: 11
Joined: 15-October 01
Member No.: 298



Some of the best minds in digital media have weighed in on this thread and think the JPlay claims are ridiculous. I agree.

As a community of developers trying to make honest products, what's the best course of action?

Is a technical trial of ridiculous claims helpful (this thread being one imperfect attempt)? Should other software actively lock JPlay out?

Thank you for any advice.

This post has been edited by monkey: Feb 15 2012, 16:28
Go to the top of the page
+Quote Post
spoon
post Feb 15 2012, 16:46
Post #23


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2741
Joined: 24-March 02
Member No.: 1615



HA I hope will always remain a fortress of common sense, outside of HA there are often huge debates about how one USB cable sounds different to another, or two bit identical files sound different to another, when faced with such, all scientific reasoning goes out of the Window. People are invested into such claims, because $ is spent achieving it, no matter what it happens to be.

Notice how the author of Jplay did not say around HA too long?, perhaps he prefers less critical climes, but there are plenty of places he would be welcomed. The emperors new clothes exists today and is centered around audio reproduction.

This post has been edited by spoon: Feb 15 2012, 16:46


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
kraut
post Feb 16 2012, 02:31
Post #24





Group: Members
Posts: 227
Joined: 24-November 10
Member No.: 85965



QUOTE
The issue at heart here is two fold:

1) HA becomes a battle ground for nonsense Audiofile claims, users who hear differences will popup, and HA will descend into trash...

Having spent - and having been locked out or removed myself voluntarily from other sites that are full bore into audiophile bullshit - I find it very important that this site stays open to critically investigate any such claims and shoot them down with all the weaponry needed.
There has to be a site one can point to and proclaim that not all interested in good audio reproduction are idiots of the special audiophile kind, where counterarguments that destroy such bullshit can be posted without the typical response by the audio idiots to squash any attempt of such discussions and push dissenter out to then freely engage in the religious aspects of audiophily....faith in your senses without proper testing is about the worst of the offenses
.
Please so not tread the path to eliminate any possibility to discuss audio fraud and ridiculous claims. This is the only site I know of that is willing to let them be taken apart piece by piece and dump on the trash heap of falsified ideas and claims.
Go to the top of the page
+Quote Post
icstm
post Feb 17 2012, 16:05
Post #25





Group: Members
Posts: 121
Joined: 25-January 12
Member No.: 96698



OK, sounds good.
So, playing devils advocate, though we mostly seem to agree that JPlay does not seem to do much, how is it there has not been a definative post to show that.

Just because the author was not able to show what improvement it DOES make, can someone not post what difference it DOES NOT make?
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th July 2014 - 08:20