Support and General Use > Audio Playback, Database and Playlists

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

(1/2) > >>

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:

--- Quote from: DTSyX on January 02, 2013, 02:32:46 AM ---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?

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page