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

[DTSyX]

[Update 23.04.2015]

See my post from 23.04.2015 (http://forums.rockbox.org/index.php/topic,42533.msg234669.html#msg234669) for the news. The problem seems to be gone with my current setup.

[/Update]


Hello,

As I read that opus ought to be a better codec than ogg vorbis, aac etc. and rockbox was supporting it in the recent builds (I'm using RockBox build 8ecbcad-121226) I transcoded a FLAC file for testing and loaded it up to my modded H140 (240GB HDD).

In general I like the sound quality, but I experience an odd way of playback on my H140. The file is encoded with 192kbit/s and ca. 8 mins of duration. Unlike when playing FLAC or .ogg files the H140 is reading constantly from the hdd during the first 3 minutes of the song, the first two of which the playback pauses every 25-30 seconds (due to lack of (or too slow) datastream I guess from the constant hdd accessing) for maybe 0,2-0,5 seconds. After the first 3 minutes the hdd accesses get rarer and at the end it's just as with .flac and .ogg files, only once in a while the hdd LED blinks.

I already checked, the file is not fragmented.
Also, if I fastforward to around minute 3 right after starting the song, there is no constant hdd access. And if I fastrewind from there to right after the beginning (around second 20) the heavy reading from hdd is absent. There are those shorts pauses though. But not at same (absolute time) positions as when played from start with all the heavy reading from hdd going on.

When playing that file from the player's hdd via usb with vlc player from my pc everything is fine, including hardly any hdd LED blinking, meaning the file itself should be fine.


I know, the opus functionality is new and at this time rather at development status, but I just would like to know if that problem is "normal" at this point of development or if it might rather a problem of my setup being a modded H140 which requires that bootloader 7 pre4, which is obviously still not a final and probably buggy.

[saratoga]

Sounds like the CPU on your player isn't fast enough for opus, at least in its current form.

[DTSyX]

Well, that's what my first thought was, too. Until I made those mentioned tests that showed, that it's not the same thoughout the file. If the cpu was the problem, shouldn't be the problem present thoughout the whole file?

I had similar experiences with aac some years ago, but there it was clear, that aac does need more cpu power (this information was to be found on the internet). I didn't check the tested file as thoughouly then as I did now with .opus. But I tested the various types of aac and could easily see that there were differences. Some did not play at all, some worse than others.

But now, I haven't found a statement of power consumption / cpu load for .opus vs. .ogg so far anywhere. That would make it more clear to me.

[Lear]

Well, that's what my first thought was, too. Until I made those mentioned tests that showed, that it's not the same thoughout the file. If the cpu was the problem, shouldn't be the problem present thoughout the whole file?

File buffering requires quite a bit of CPU as well. The initial behavior sounds typical to when Rockbox doesn't have a lot of CPU time to buffer the file. But once it is buffered, you only get the short pauses, because the CPU isn't quite fast enough to be able to decode the file in realtime. If you fast forward during the initial buffering, Rockbox won't actually decode the file during the seek, so the buffering might well finish during that time. And when rewinding, the file doesn't need to be buffered again.

[donp]

You could try a lower bit rate.  On my older Sansa,  128k is similar to your symptoms (plus total lockup if you try something like skip track), 64k is about the ragged edge (plays 100%, but not enough extra cpu to run the display and controls without noticeable lag), 48k works well.   Maybe your "works well" point will be higher.

I believe the decoder will be more efficient in time.  Until then (or the player dies and gets replaced with a faster one), I am only going wholesale to opus for speech, which is certainly ABX'able but really good enough at 10 or 12 kb/s.

[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]

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.

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.

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.

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!