[DEV] Compiling mplayer
- Thread starter sandmen
- Start date
I've been trying to get audio working, although in a Magic 32B, but I have failed so far.
Do you Hero owners see /dev/dsp or /dev/snd0 ?
Do you get any audio at all? If so, using what device?
From the very limited information I've managed to get so far, Dream owners do get sound, though I have no idea how and why.
I've used the how-to mentioned in the first post, no success so far.
Do you Hero owners see /dev/dsp or /dev/snd0 ?
Do you get any audio at all? If so, using what device?
From the very limited information I've managed to get so far, Dream owners do get sound, though I have no idea how and why.
I've used the how-to mentioned in the first post, no success so far.
Perhaps this helps: read-write access for /dev/msm_pcm_out
So chmod this device file and use it as audio out?
I'm actually curious about how a native linux app would render video on android. There is no X so framebuffer would be the only way. But then, how do you get user in/output?
So chmod this device file and use it as audio out?
I'm actually curious about how a native linux app would render video on android. There is no X so framebuffer would be the only way. But then, how do you get user in/output?
status mplayer crosscompilation
@all
follow things i have tryed:
- Crosscompiling svn-version mplayer, there i have some segmentation fault's.
doesn't work
- Crosscompiling Mplayer1.02 (old version) there i have trouble to set VSCREENINFO.
So it takes time
If anybody have some hints, about crosscompiling, feel free.
@all
follow things i have tryed:
- Crosscompiling svn-version mplayer, there i have some segmentation fault's.
doesn't work
- Crosscompiling Mplayer1.02 (old version) there i have trouble to set VSCREENINFO.
So it takes time
If anybody have some hints, about crosscompiling, feel free.
@all
follow things i have tryed:
- Crosscompiling svn-version mplayer, there i have some segmentation fault's.
doesn't work
- Crosscompiling Mplayer1.02 (old version) there i have trouble to set VSCREENINFO.
So it takes time
If anybody have some hints, about crosscompiling, feel free.
I managed to compile a working (by working I mean no segfault
) version of SVN-r29796 with the following config:./configure --enable-fbdev --host-cc=gcc --target=arm --cc=arm-none-linux-gnueabi-gcc --as=arm-none-linux-gnueabi --ar=arm-none-linux-gnueabi-ar --ranlib=arm-none-linux-gnueabi-ranlib --enable-static
The resulting binary can be found here:
http://www.megaupload.com/?d=142QK29B
Together we can solve this, sandmen
What we need now is a Dream user to confirm that audio works on that hardware...
No, I get the VSCREENINFO error. It does decode video though if I use "-vo null -ao null", but what probably won't get us anywhere...
I've heard the VSCREENINFO problem is a kernel bug, can anyone confirm this?
I don't have the time to look into it now, but maybe we can make a patch to workaround the problem?
Edit:
It seems like this piece of code in libvo/vo_fbdev.c is causing the problem:
Code:
if (ioctl(fb_dev_fd, FBIOGET_VSCREENINFO, &fb_vinfo)) {
mp_msg(MSGT_VO, MSGL_ERR, "Can't get VSCREENINFO: %s\n", strerror(errno));
goto err_out;
}The problem is that my C skills are very limited and I have no idea what "&fb_vinfo" should be... C coders please help?
Typing "ioctl FBIOGET_VSCREENINFO" returns "ioctl: too few arguments".
Typing "ioctl FBIOGET_VSCREENINFO 0" returns "cannot open FBIOGET_VSCREENINFO"
From the information I can gather, ioctl seems to be a tool to pass instructions directly to drivers?
Yeah, it finally seems like we're getting somewhere
Last edited:
I've tried this, "-ao oss:/dev/msm_pcm_out" gives "Can't set audio device /dev/msm_pcm_out to s16le output, trying s16le...".
"-ao pcm:file=/dev/msm_pcm_out" hangs MPlayer at the "Starting playback..." message.
"-ao pcm:file=/dev/msm_pcm_out -v" hangs MPlayer with the line "Increasing filtered audio buffer size from 0 to 65536".
So yes, it might be the right device, but I can't get it to work.
Perhaps you could download the binary and see if you get different results on a Hero?
Wow, do I feel stupid
Of course it's the put VSCREEN error, here is the correct code from libvo/vo_fbdev.c:
Code:
if (ioctl(fb_dev_fd, FBIOPUT_VSCREENINFO, &fb_vinfo)) {
mp_msg(MSGT_VO, MSGL_ERR, "Can't put VSCREENINFO: %s\n", strerror(errno));
if (fb_tty_fd >= 0 && ioctl(fb_tty_fd, KDSETMODE, KD_TEXT) < 0) {
mp_msg(MSGT_VO, MSGL_ERR, "Can't restore text mode: %s\n", strerror(errno));
}
return 1;
}It seems like the problem mostly remains the same.
However, I can't debug it properly (yet!) due to my lack of skills in C
.I'm making slow progress in understanding the real problem, but at least I'm learning some C while I'm doing it
Edit:
I've looked through the sources and I just can't figure it out:
Code:
static struct fb_var_screeninfo fb_vinfo;But fb_var_screeninfo itself (defined in linux/fb.h) looks like this (copied directly form android kernel git tree):
Code:
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
__u32 activate; /* see FB_ACTIVATE_* */
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 rotate; /* angle we rotate counter clockwise */
__u32 reserved[5]; /* Reserved for future compatibility */
};My conclusion so far is that one of these parameters are unsupported by the HTC Magic's graphics driver, but not the HTC Dream graphics driver?
I have no idea why the driver would even differ between them; they both use the same graphics chip, don't they?
Last edited:
Already tried that, I usually use root when debugging inside of Android, but not even "chmod 777 /dev/msm_pcm_out" helps.
I noticed there might be some relevant libraries in android:
/lib//libaudio.so
/lib/libhardware.so
/lib/libhtc_acoustics.so
/lib/libmedia.so
/lib/libmm-adspsvc.so
/lib/libopencore_player.so
/lib/libsoundpool.so
/lib/bluez-plugin/audio.so
Surely at least one of these libraries can provide a way to output audio?
Except maybe that bluez thing
Great, finally a Dream user (maybe thread should be moved to the Dream Development sub forum, as that's where people look for general android discussions).
Anyway, it's publicly available here:
http://www.megaupload.com/?d=142QK29B
Version SVN-r29796 for now, will probably upgrade later and post link here.
Save it to a SD card and use 'sh mplayer mediafilegoeshere.example -ao oss:/dev/msm_pcm_out' and post the results here.
Since you have a HTC Dream, it would be great if you could confirm it working/broken without the '-ao oss:/dev/msm_pcm/out' part.
Thanks for your help
Similar threads
