Issue with Audacious play mp3 on ac100
Bug #1072696 reported by
saturn
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mpg123 (Debian) |
Fix Released
|
Unknown
|
|||
mpg123 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Attempt to open mp3 return "...mpg123: Error opening file a.mp3: Unable to set up output format! (code 1)."
This bug with solution discussed already here http://
After recompiling and updating libmpg123 according to this discussion audacious now works fine.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libmpg123-0 1.14.2+
Uname: Linux 3.1.10-6-ac100 armv7l
ApportVersion: 2.6.1-0ubuntu6
Architecture: armhf
Date: Mon Oct 29 16:03:47 2012
MarkForUpload: True
SourcePackage: mpg123
UpgradeStatus: No upgrade log present (probably fresh install)
Related branches
information type: | Public → Public Security |
information type: | Public Security → Public |
Changed in mpg123 (Debian): | |
status: | Unknown → Fix Released |
To post a comment you must log in.
Am Mon, 29 Oct 2012 12:19:50 -0000
schrieb saturn <email address hidden>:
> Attempt to open mp3 return "...mpg123: Error opening file a.mp3: Unable redmine. audacious- org/boards/ 2/topics/ 315
> to set up output format! (code 1)."
>
> This bug with solution discussed already here http://
> media-player.
Um, people want everything, eh? Well, there is some wrong and some
correct information there. The solution of using generic C code works
for getting all output formats, yes (John Lindgren got a wrong
impression there about float output being coupled to assembly
optimizations).
But there also is assembly-optimized decoding to floating point on ARM
platforms that feature the NEON instructions (Cortex A8). There is no
common build encompassing the different variants like x86 and it is not
likely that there will be, as the normal ARM does integer math. There
might be a build that combines ARM NEON with generic C fallback code,
using floating point math.
When audacious insists on floating point data, even on machines that do
not feature floating point hardware, you have some options:
a) build mpg123 with generic_fpu ... which makes it relatively slow for
normal 16-bit playback (or in ARM terms: consuming too much energy),
b) patch audacious mpg123 binding to convert 16 bit to float on-the-fly or
c) patch mpg123 (or motivate a release) to do that float conversion
after decoding, just like 24 bit or unsigned integer types are
handled right now.
I see a point for the latter one ... it would not be hard to do it.
Just a bit pointless in case this is running on a CPU that has working
floating point support, or NEON, even.
Thoughts from debian? I see this being a problem for packaging as you
have to decide for one mpg123 build for stand-alone operation and
linking to audacious. Compromises suck.
Alrighty then,
Thomas