Support and General Use > Audio Playback, Database and Playlists

[Resolved] .opus playback issue on iRiver H140 (on RockBox build 8ecbcad-121226)

<< < (2/2)

DTSyX:
After my first (dissappointing) tests with .opus I did a "final" one. I paused the track right after starting it and waited until the loading (excessive hdd access) was done. Then I resumed.
 
The result supports what Lear stated independently from my test: The short pauses still were there, but the hdd access was down to normal. Suggesting that the cpu of the H140 really isn't fast enough. I experienced that with .aac a few years back which lead me to never consider .aac as my favourite standard format again.
I just thought, given that .opus also comes from xiph as does ogg vorbis, it would be equally easy on the cpu requirements. But on the other hand, if it's better than .ogg it has to be more efficiently compressed and therefor automatically need more cpu power.
 
The only thing I still don't quite understand is why those short pauses only occure in the first half or so of the file. The decoding requirements should be about the same throughout the file provided the audio content complexity doesn't change too much during the track.
 
And regarding donp's proposal: It doesn't make much sense to lower the quality just to make the playback be flawless. I rather stick to ogg vorbis, which is still a good codec. It's been good enough for all these years for me. And for my essential albums I use .flac anyway.
So, I don't "have" to use .opus. But it would have been nice to be able to switch to a even better lossy codec.

All in all, not really a biggy. :-)

wodz:
Opus is hybrid codec. It may happen that part of the file is cheaper to decode then the rest.

saratoga:

--- Quote from: DTSyX on January 15, 2013, 09:39:43 AM ---I just thought, given that .opus also comes from xiph as does ogg vorbis, it would be equally easy on the cpu requirements. But on the other hand, if it's better than .ogg it has to be more efficiently compressed and therefor automatically need more cpu power.
--- End quote ---

It is quite efficient, just not optimized for a CPU that hasn't been used in audio players in the better part of a decade.


--- Quote from: DTSyX on January 15, 2013, 09:39:43 AM ---
The only thing I still don't quite understand is why those short pauses only occure in the first half or so of the file. The decoding requirements should be about the same throughout the file provided the audio content complexity doesn't change too much during the track.
--- End quote ---

Did you see lear's post above where he explains that file buffering takes quite a lot of CPU (and thus leaves less for decode)?
 

DTSyX:
I'm happy to report that apparently now .opus works fine on my H140.

I'm not sure what the reason is. I updated to a mid-april (2015) build and I switched to ssd instead of hdd. So it can be one of the "major changes since 3.13", i.e. "slightly improved audio quality on H100" and/or the (several) "optimizations for Opus", and/or the speed advantage of the ssd over the hdd.

Anyway. I just tested my test album I converted back when I first tried opus (so no recently encoded files and therefore all the same on the input side) and it played without gaps or pauses. Of cause there was this phase of heavy reading from the ssd after starting playing the file(s) - which is to be expected for a highly efficient codec in combination with an very old cpu -, but other than that there seems nothing wrong with using .opus on H1xx anymore.

Thanks, guys for your great work!

Navigation

[0] Message Index

[*] Previous page