Gmu 0.10.1 released!
I have just released version 0.10.1 of the Gmu Music Player. It is mostly a bugfix release.
Most notably it fixes some issues with the build process which could occur on some systems.
Other than that I have improved some of the decoders.
The Opus decoder now supports seeking, while the Ogg Vorbis decoder accepts files with the .oga extension (in addition to the more popular .ogg file extension).
For more information about Gmu 0.10.x please have a look at the Gmu 0.10.0 release post
Source gmu-0.10.1.tar.gz (487 KB)
Hi danke für das Update.
Ich werde gerne probieren das mit Code-Blocks auf die Pandora zu porten :D
Oh :) brilliant .oga file ext support and opus support improvements!
Thanks so much for your work, Keep it up! (and keep it fun for your self too, ;) .)
One advanced feature i think about is a 2rd audio output so with a usb audio interface. there are two outputs, one for speakers and one for a preview of the current selected/highlighted track in the file browser/playlist. For me, it would make it a lot easier to choose the next track to play at parties :D. GMU - the mini basic dj :)
ow i forgot to say that preview was via headphones via the 2rd output.
Alexander Ross: That is an interesting idea. I have thought about some party usage features myself. For something like that the biggest issue right now would be the SDL library. At least SDL 1.2 (which I am currently using for compatibility reasons with older devices) does not support multiple audio outputs as far as I can tell. Since I was thinking about changing the audio output code to not use SDL anyway I might consider adding the option for multiple device outputs in case I do actually change the audio output code.
I finally got around to building gmu 0.10.1 for openwrt on the zipit, mostly because aRoss has been agitating to try some opus streams in gmu. But it looks like there's a buffering issue. Gmu pauses for a while, then plays a tiny sample and gives up. When I open an mp3 stream and log with -v 5 debug it prints "reader: buf fill 270000 bytes" (or so) while playing, but opus prints "reader: buf fill 1700" or thereabouts. Eventually it gives up and moves on to the next stream. Meanwhile wget piped to opusdec piped to aplay works fine with plenty of cpu headroom on the same opus streams. Got any suggestions what I could try to tweak in the gmu opus decode path?
deeice: That's weird. I don't have an idea right now, but I would like to investigate the issue. If the buffer doesn't fill, it doesn't look like it is a CPU usage issue. Does it happen with all Opus streams? Do you have an example stream?