Triode wrote:
> Is this with transcoding required or also the case for files which can
> be played natively by the dac? Can't do anything about cpu load of
> transcoding.
Yes, the core of the problem is CPU load caused by sox. It sucks up CPU
cycles, if I degrade the resampling quality I improve -not enough- the
CPU situation but I introduce audible artefacts. I suspect sox is being
a bad neighbour, I could get continuous audio without starving on
buffers if sox wasn't so brutal in its CPU access. It goes for speed,
but x1.01 transcoding speed would be enough
ulimit won't help, I may
try with cpulimit (hum, another daemon
) or cfs/cgroups in kernel 3.2.
(anybody knows something about this, please tell me before I start.)
Without sox, SBS+squeezelite is fine on the Geode. Not as smooth as on
the Aspire One (atom); it has less headroom and runs more services
(although it doesn't have to drag Gnome along)
Right now I run a no-preempt, 100Hz tick, 2.6.32 kernel compiled for the
Geode. FYI I recompiled sox and squeezelite with what could be Geode
LX-optimized gcc options ('comment #6 here'
(http://www.twam.info/hardware/chost-i586-vs-i486-on-amd-geode-lx#comment-130))
but that didn't change much the end result. I don't see much gain in
this kernel setup either, I may revert to a standard tickless or 250Hz
one later.
Playing material compatible with the DAC capabilities, I can get the
occasional pop/click in the v-dac mk 1, I suppose this is due to its
synchronous nature. I'd like to find a dirt-cheap usb-toslink or usb dac
that has its own buffer and clock to ride over transients, but all the
information I've found on the web until now is either extremely
technical or extremely
audiophile.
This has nothing to do with squeezelite anyway. I don't expect it to
"lift the veil" on my musical experience or something.
Yesterday I set SBS on the Geode to run with "--noupnp --nosb1slimp3sync
--nodebuglog --noweb". SBS runs at normal priority. Squeezelite is
reniced -20. CPU load when a song is playing for a while is < 5%
(without sox of course.) Player responsiveness is very good from iPeng.
When I get an album from the library and play it, SBS can spike to using
80% of the CPU for itself (more often 40%.) The first seconds of the
album can sometimes be garbled a bit. Not always.
When I get an album from the library, hit play, immediately go back to
the library and hit play on another album, then it is SqueezeLite that
can hog 100% of the CPU for a little while (under a minute.) This is
repeatable.
Since squeezelite loads the CPU so much at that moment (and it is
reniced), SBS can't get the CPU for itself like it would want. The end
result is a non-responsive iPeng interface and no audio (or interrupted
audio) during the period.
I don't think there is an option in SBS that would allow the player to
wait a bit before starting (hence let CPU load quiesce) ?
Anyway, as much as I dislike squeezeboxes in a sandwich box, tinkering
with alsa and usb audio, SqueezeLite got me excited and it works
extremely well. It's going to be a part of my geode server project,
because it adds value and usefulness to the package.
I'm sure I won't be the last one to thank you on a great contribution
and your dedication to the community.
------------------------------------------------------------------------
epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711
View this thread: http://forums.slimdevices.com/showthread.php?t=97046
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
