Skip to main content

Topic: RAM access speed tests with a few players (Read 8425 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • JimH
  • [*][*][*]
RAM access speed tests with a few players
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

  • probedb
  • [*][*][*][*][*]
RAM access speed tests with a few players
Reply #1
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.

  • JimH
  • [*][*][*]
RAM access speed tests with a few players
Reply #2
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)"

  • Batman321
  • [*][*]
RAM access speed tests with a few players
Reply #3
What about Winamp?

  • monkey
  • [*]
  • Developer
RAM access speed tests with a few players
Reply #4
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.

RAM access speed tests with a few players
Reply #5
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?

  • JimH
  • [*][*][*]
RAM access speed tests with a few players
Reply #6
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.

  • monkey
  • [*]
  • Developer
RAM access speed tests with a few players
Reply #7
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
  • Last Edit: 14 February, 2012, 02:15:14 PM by monkey

  • JJZolx
  • [*][*][*][*]
RAM access speed tests with a few players
Reply #8
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: [Select]
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
  • Last Edit: 14 February, 2012, 02:39:52 PM by JJZolx

  • saratoga
  • [*][*][*][*][*]
RAM access speed tests with a few players
Reply #9
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.


  • Porcus
  • [*][*][*][*][*]
RAM access speed tests with a few players
Reply #10
Quote
(higher is better)


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

  • monkey
  • [*]
  • Developer
RAM access speed tests with a few players
Reply #11
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.

  • JimH
  • [*][*][*]
RAM access speed tests with a few players
Reply #12
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.

  • spoon
  • [*][*][*][*][*]
  • Administrator
RAM access speed tests with a few players
Reply #13
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)...

  • Kohlrabi
  • [*][*][*][*][*]
  • Global Moderator
RAM access speed tests with a few players
Reply #14
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.
  • Last Edit: 14 February, 2012, 05:33:22 PM by Kohlrabi
It's only audiophile if it's inconvenient.

  • monkey
  • [*]
  • Developer
RAM access speed tests with a few players
Reply #15
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.

  • JimH
  • [*][*][*]
RAM access speed tests with a few players
Reply #16
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

  • JimH
  • [*][*][*]
RAM access speed tests with a few players
Reply #17
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.

  • Kohlrabi
  • [*][*][*][*][*]
  • Global Moderator
RAM access speed tests with a few players
Reply #18
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.
  • Last Edit: 15 February, 2012, 09:14:47 AM by Kohlrabi
It's only audiophile if it's inconvenient.

  • spoon
  • [*][*][*][*][*]
  • Administrator
RAM access speed tests with a few players
Reply #19
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.

  • Peter
  • [*][*][*][*][*]
  • Administrator
RAM access speed tests with a few players
Reply #20
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).

  • monkey
  • [*]
  • Developer
RAM access speed tests with a few players
Reply #21
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.
  • Last Edit: 15 February, 2012, 10:28:53 AM by monkey

  • spoon
  • [*][*][*][*][*]
  • Administrator
RAM access speed tests with a few players
Reply #22
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.
  • Last Edit: 15 February, 2012, 10:46:53 AM by spoon

  • kraut
  • [*][*][*]
RAM access speed tests with a few players
Reply #23
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.

  • icstm
  • [*][*][*]
RAM access speed tests with a few players
Reply #24
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?