Converting AIFF files to WAVE does it improve sound

[yamamoto2002]

6 years ago, I benchmarked byte reordering code for AIFF reading and found my not-so-optimized code converts AIFF (715MB, contains entire CD PCM) to little-endian byte order in 0.11 second on my Mac Mini Mid 2010.  Computer is very good at byte reordering task.

 

ARM processors used for mobile phones have dedicated SIMD instruction for this task, VREV16 instruction that reorders 4 big-endian PCM samples to little-endian in one instruction on one CPU core!

 

[audiventory]

37 minutes ago, yamamoto2002 said:

6 years ago, I benchmarked byte reordering code for AIFF reading and found my not-so-optimized code converts AIFF (715MB, contains entire CD PCM) to little-endian byte order in 0.11 second on my Mac Mini Mid 2010.  Computer is very good at byte reordering task.

 

ARM processors used for mobile phones have dedicated SIMD instruction for this task, VREV16 instruction that reorders 4 big-endian PCM samples to little-endian in one instruction on one CPU core!

 

Of course better avoid any swaping and data arrays transfers.

 

But 0.11s/715 MB is nothing comparing filtering or resampling

 

Also comparing operations (if/else) consume many resources.

 

I mean C/C++ languages.

 

 

[yamamoto2002]

Sorry I rechecked the development diary and found the processor used was Intel Xeon W3680, not Core2Duo of Mac Mini Mid 2010

 

Tested data was AIFF ripped from CD, Boulez conducts Debussy La Mer from Deutsche Grammophon

Track1 63MB 0.011 sec

Track2 65MB 0.011 sec

Track3 98MB 0.014 sec

Track4 87MB 0.016 sec

Track5 162MB 0.027 sec

Track6 88MB 0.014 sec

Track7 72MB 0.009 sec

Track8 77MB 0.012 sec

Total 712MB 0.114 sec

 

Following C# code was used for benchmarking.

https://sourceforge.net/p/playpcmwin/code/HEAD/tree/PlayPcmWin/PlayPcmWin/AiffReader.cs#l443

[audiventory]

Yamamoto2002,

May be on C/C++ you get better results.

Personally I don't work with C#, but my friends says (who came to C# from C for faster development), what it is not most fast language for signal processing.

[Jud]

9 minutes ago, audiventory said:

Personally I don't work with C#, but my friends says (who came to C# from C for faster development), what it is not most fast language for signal processing.

 

Wasn't this MS's attempt to develop a Java equivalent?  Java is not noted for its speed either.

[Ralf11]

RTOS used to be a good OS for signal processing - but that was long ago in a different universe

[yamamoto2002]

5 hours ago, audiventory said:

Yamamoto2002,

May be on C/C++ you get better results.

Personally I don't work with C#, but my friends says (who came to C# from C for faster development), what it is not most fast language for signal processing.

 

Yes it is correct. I estimated the room for improvement of this code and it will be approx 3x or 4x faster with further optimization such as rewriting with more efficient language.

[Superdad]

On 3/21/2017 at 4:25 AM, Cebolla said:

Even in jest, the Señor Member comes complete with huevos.

Eggs?  Don't you mean cojones?

(Though I do enjoy huevos cojones--over easy.  )

[Jud]

24 minutes ago, Superdad said:

Eggs?  Don't you mean cojones?

(Though I do enjoy huevos cojones--over easy.  )

 

Oh, I've seen 'em referred to that way.  One of those things there are a hundred terms for....

[Superdad]

2 minutes ago, Jud said:

 

Oh, I've seen 'em referred to that way.  One of those things there are a hundred terms for....

However we refer, we know you have a lot of 'em my friend! 

[Cebolla]

44 minutes ago, Superdad said:

Eggs?  Don't you mean cojones?

(Though I do enjoy huevos cojones--over easy.  )

I would be cautious about saying how much you enjoy huevos cojones, over easy or otherwise. There may be some Spanish speakers out there quite willing to offer you a double helping!

[Jud]

2 minutes ago, Cebolla said:

I would be cautious about saying how much you enjoy huevos cojones, over easy or otherwise. There may be some Spanish speakers out there quite willing to offer you a double helping!

 

Where is that "wince" emoji? 

 

I hear huevos are good with onions as well.

 

[miguelito]

On ‎3‎/‎10‎/‎2017 at 2:14 AM, wgscott said:

Things like md5sums and bit-identical file

comparisons are ideological constructions of the lamestream media and the kultcheral eleet. Alternative facts are at play here, and every opinion is subjective and equally meritorious. So just follow your ears and our President's proclamations.

Sad!

[Cebolla]

6 minutes ago, Jud said:

Where is that "wince" emoji? 

 

I hear huevos are good with onions as well.

 

True and this Cebolla's own are enough for me (I'm wincing now)!

[audiventory]

On 21.03.2017 at 9:08 PM, Jud said:

 

Wasn't this MS's attempt to develop a Java equivalent?  Java is not noted for its speed either.

 

Yes. It was intended as crossplatform decission.

 

I don't follow this platform business development. Probably now, it is reality.

 

I'm more interesting in product creation than useles learning new programming technologies, that permanently obsoleted :-)

 

I take new programming technologies, if it obviously promiss me big step forward.

[audiventory]

23 hours ago, Ralf11 said:

RTOS used to be a good OS for signal processing - but that was long ago in a different universe

 

It is interesting issue.

 

RTOS (guaranteed reply time of system on event) in audio have no big sense.

 

Because, if system have no computing resources, RTOS can't work.

 

If system have resources, all time issues solved via buffering in RAM and in DAC's buffer. "RTOS" work in usual DAC here :-)

 

RTOS systems need for cars, plans, robots, etc. For allications that demands guaranteed time of reply on event (changing wheel position on changing sensor condition, as example).

[Jud]

17 minutes ago, audiventory said:

 

Yes. It was intended as crossplatform decission.

 

I don't follow this platform business development. Probably now, it is reality.

 

I'm more interesting in product creation than useles learning new programming technologies, that permanently obsoleted :-)

 

I take new programming technologies, if it obviously promiss me big step forward.

 

I suppose cross-platform stuff can't be the most efficient because it requires a compatibility layer.  So if you need speed, you use something else.

[Ralf11]

back in ye olden days, people would test the code to see where the bottlenecks were, then redo those modules in assembler... 

[mansr]

2 minutes ago, Ralf11 said:

back in ye olden days, people would test the code to see where the bottlenecks were, then redo those modules in assembler... 

 

This is still done by anyone who cares about performance. Compilers are good, but a skilled assembly programmer can usually outperform them by a factor 2-4, sometimes much more. The trick is to organise the code such that the most time-consuming parts are contained and easy to write in assembly.

[Jud]

10 minutes ago, Ralf11 said:

back in ye olden days, people would test the code to see where the bottlenecks were, then redo those modules in assembler... 

 

Back in older days than those, I watched my friend punch holes in paper tape and feed it to a spanking new PDP-11.

 

People still use assembly language, of course.

[yamamoto2002]

I think bottleneck of my implementation still in CPU and there is room for optimization. for example if bottleneck moves from CPU to bandwidth of memory by optimizing, it is one of the milestone for optimization, where data throughput does not improve anymore because CPU waits until new data is arrived from memory.

 

But I stopped optimization there because, I thought at that time, it is no meaning to improve already fast enough part of the program, no one appreciate if file loading task of 700MB becomes quicker by 0.08 second by further optimization.

 

Of course there are another opinion there, some people think it is some sort of unscrupulous to run inefficient code because it is waste of energy resource

[mansr]

1 minute ago, yamamoto2002 said:

I think bottleneck of my implementation still in CPU and there is room for optimization. for example if bottleneck moves from CPU to bandwidth of memory, it is one of the milestone for optimization, where data throughput does not improve anymore because CPU waits until data is arrived.

 

But I stopped optimization there because, I thought at that time, it is no meaning to improve already fast code, no one appreciate if file loading task of 700MB becomes quicker by 0.08 second by further optimization.

 

Of course there are another opinion there, some people think it is some sort of unscrupulous to run inefficient code because it is waste of energy resource

 

Your bottleneck is almost certainly I/O, at least in any realistic scenario.

[audiventory]

6 hours ago, mansr said:

 

Your bottleneck is almost certainly I/O, at least in any realistic scenario.

 

As rule, the bottleneck in "if ... then ... else..." constructions first.

 

If no other very obvious way, need minimize condition control.

 

After it need minimize memory copy places (there conditions checked too).

 

Though need begin from local/portional code-execution time measurement.

 

Other wise many efforts may be wasted.

 

Sometimes no sense optimize something, if it work good for user or many efforts increase performance too small.

 

6 hours ago, yamamoto2002 said:

Of course there are another opinion there, some people think it is some sort of unscrupulous to run inefficient code because it is waste of energy resource

 

It may be solved via one time pre-conversion to format/form what played back in bit-perfect mode without/with minimum "on fly" processing.

[No Disc]

One CA member has done extensive listening and testing.  The results are here:

 

 

[mansr]

5 hours ago, audiventory said:

As rule, the bottleneck in "if ... then ... else..." constructions first.

 

For tight processing loops, yes. What we're talking about here is essentially a file copy, and there the disk I/O dominates unless it's a RAM filesystem.