Let’s continue where I’ve stopped yesterday, with writing at least, as there is still some stuff I’ve done which I haven’t written down yet.
Well… let’s see, where was I… so I wrote about installing xfce4 and qmmp and so. Well, we’ve got qmmp, we’ve got the nfs on the server Pi mounted. So let’s play some music, shall we? Well…. no…. no audio device found. The reason for this is that the audio driver was not loaded. So adding snd-bcm2835 to the modules to be loaded solved that problem.
The audio driver is loaded, but still no sound. I am using the HDMI->VGA adaptor. The only HDMI->DVI cable I’ve got is 5 meters long and rather this, so this is a clumsy cable. Therefore I am using a short thing VGA cable with that adaptor. It’s rather inefficient to connect a digital (flat) monitor over an analogue interface, but whatever. The problem is, this HMDI to VGA adaptor does pass through the EDID information from the monitor, however, it falsely claims to support audio, therefore the Raspberry Pi attempts to send the audio over the HDMI interface. So we have to force the analogue output.
This can be done using the following command
amixer cset numid=3 1
Well.. I have sound, but, it’s only mono.
Simple mixer control 'PCM',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback -10239 - 400
Mono: Playback -1500 [82%] [-15.00dB] [on]
Speaker test gives
[andre@rpi ~]$ speaker-test
speaker-test 1.0.26
Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 512 to 16384
Period size range from 512 to 16384
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
0 - Front Left
Time per period = 2,326930
0 - Front Left
On some forum. I’ve read a comment this may be caused by a bad cable, causing the Pi to detect only one of the speakers. I have tried headphones and my stereo tower, but still it says Mono. I cannot find where I’ve read this right now, but when searching I’ve found different answers to this problem. It seems this only means the mixer doesn’t support per channel volume control. Running speaker test telling it to use two speakers shows everything works as it should.
[andre@rpi ~]$ speaker-test -c 2
speaker-test 1.0.26
Playback device is default
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 256 to 8192
Period size range from 256 to 8192
Using max buffer size 8192
Periods = 4
was set period_size = 2048
was set buffer_size = 8192
0 - Front Left
1 - Front Right
Time per period = 5,663562
0 - Front Left
1 - Front Right
Another thing I’ve tried is to connect a CRT monitor to my HDMI->VGA adaptor. After all, VGA is an analogue interface, and makes much more sense for a real analogue monitor. The system boots up correctly immediately. It doesn’t have the first boot out of sync problem with my flat monitor. The CRT monitor is a 17″ Philips 107G5. One thing to notice is it comes up at 1280×720 with a refresh rate of 60 Hz. This is the “HD 720p60” resolution, right? The reason for this is that the resolution/refresh rate is within the supported range, and as it is an analogue monitor, it doesn’t have a “preferred” resolution.
Using the method for resolution setting as discussed before, the correct resolution can be set
tvservice -e="DMT 19"
fbset -xres 1024 -yres 768 -a
or through the /boot/config.txt file
# Philips 107G5
disable_overscan=1
hdmi_group=2
hdmi_mode=19
hdmi_drive=1
But, this brings me to my CubieBoard. As I mentioned, my Compaq 1720 flat monitor doesn’t accept the output from my CubieBoard. As I’ve understood from forums, it outputs 720p60. So I’ve connected the HDMI->VGA adaptor to the CubieBoard again, and booted it without µSD card. Android boots, and indeed shows output on the screen. So, I’ve verified it’s graphical output is working. However booting on the µSD card gave no graphical output yet. As mentioned before, it’s a possibility the kernel I’m using doesn’t have the framebuffer enabled. Anyhow, the hardware is fine, it’s a software problem.
Another problem that arised is the CubieBoard to fall out halfway during boot. I am using my Phone’s charger (850 mA) to power the Raspberry Pi, but it seems it’s not strong enough to power the CubieBoard with the HDMI output enabled. The CubieBoard ran fine without graphical output enabled. As I am using a powered USB hub. (Even though its power supply is 1 A for 4 USB ports, which should be 500 mA per port, so at least 2 A + power needs for the hub itself). So, I wonder if this is even allowed according to the USB specs. However, I plugged in the CubieBoard’s power cable into that hub, which is also against the USB specifications, to draw power from the bus without any USB logic reporting the amount of energy being drained, and getting approved by the USB host. Besides missing the USB logic it is also drawing over 500 mA, another violation of the USB specifications. So… this is blatantly violating the USB specifications, it seems to work.
Another thing that’s blatantly violating specifications is the OpenMAX implementation on the Raspberry Pi. This is the cause an OpenMAX enabled VLC build doesn’t work on the Raspberry Pi. But it’s not only the Raspberry Pi’s library fault. Even though the problem on the VLC part is rather small, being the filename of the library, being hard-coded for various implementations of OpenMAX, not including the Raspberry Pi’s filename.
Well… as I’ve builded VLC anyways, from the source tarball, I’ll write about doing that as well. Usually software is built through a PKGBUILD patching all problems away. So we call the configure script with the “–enable-omxil” parameter. As it complains about missing gl package, I’m also adding “–disable-glx”, as I’m interested in the OpenMAX plugin.
[andre@rpi vlc-2.0.5]$ ./configure --enable-omxil --disable-glx
VLC depends on LUA version 5.1, and won’t compile with 5.2. Since the filenames for LUA 5.1 are postfixes with their filenames, making a synlink to the un-postfixed is required to make the ./configure script find lua.
Anyhow… this explains why the Raspberry Pi version of XBMC doesn’t use OpenMAX but some custom integrated component on the Raspberry Pi. Anyhow I’ve installed omxplayer, but as it just writes the movie to the framebuffer, but doesn’t erase the borders, it’s not really an option for watching movies on the Pi, at least, not without some additional tools. So, I’m currently building the mentioned XBMC.
Trying to build XBMC (from AUR) showed some other problems. Namely, the /tmp is by default a tmpfs. This is like a RAMdisk in the old DOS days, a part of memory used as a file system. But it’s way too small to build XBMC. Therefore I’m using the hard disk as /tmp.
/home/tmp /tmp none bind 0 0
And now…. I am just waiting for it to finish compiling….. which can take ages… so perhaps one of my next projects is setting up distcc to perform the compiling on a faster machine. NOTE TO SELF: Finish configuring the Raspberry Pi Server first!!! It still needs a sane server, IPv6 configuration, git server, web server!!!
Anyhow speaking about this Media Center software, I also have this DreamBox DM-7000S. It was still running PLi 2009-06-27. Even though nothing new shows up in the opdates, it seems they’ve changed to OpenPLI. So I’ve flashed a new image into my DreamBox. So…. my software is again up to date. Apart from that I’ve swapped the SCART cable with the DVD player, now the snow I was getting is gone. But on the DVD player there is no slow either. I suppose it was just a bad contact.
I have been looking around for a new DreamBox, even though I don’t have a HD-TV, and I am not planning to get one either. But the regional channels are MPEG-4 encoded and so won’t work with the DM-7000S. Well… my dish isn’t aligned correctly for 23.5E anyways so I won’t receive the regional channels anyways. So, a DM-8000 is interesting, I’ve been looking at this for years, but the price is keeping me back. € 875 is a little too much for just a satellite receiver. Ok, there are cheaper stores, but € 819 is still rather high. Ok, there are cheaper DreamBoxes, but I want one that can decode MPEG-4 and offers recording to hard disk. The DM 8000 offers the possibility to install tuner modules so we can receive, apart from DVB-S/DVB-S2 also DVB-T or DVB-C.
Well… since I was looking at this XBMC stuff…. what about turning a Raspberry Pi into a complete Media Center including DVB. Cheap DVB-T receivers are available at DX.com. They seem to offer only one USB DVB-S receiver, but at it mentions only DVB-S and not DVB-S2, it’s not capable to receive HD channels as they use a different modulation. Looking around on the internet found me this receiver.
When thinking about tuning a Raspberry Pi into a satellite receiver, we need to think about the fact all Dutch TV Channels are encrypted. *sigh* Why do they have to do this? Most German channels are FTA for example. Anyhow, on my DreamBox I am using the integrated card reader, as the MatrixCAM Reloaded and MatrixCAM Revolutions, which I used to use in the past, on this and other receivers, show incompatibility issues with the new Smart Cards supplied by CanalDigitaal and freezes regulary, requiring the CA to be powercycled. Using the integrated Smart Card reader and a softcam CCcam the Smart Card works without problems.
Well… CCcam… it’s a proprietary piece of software… so it’s not ideal. There is OScam, which is open source, but it appears not to be available in the OpenPLi DM7000 repository, and since CCcam works, I keep using it. Well… the point is. CCcam can be used as a Softcam for my Smart Card. So adding USB Smart Card Readerto the list of required components for turning the Pi into a satellite receiver. It seems there also exist a multi card version.
If it would be required in the future to use an official CanalDigitaal CAM, USB CASes (1) (2) are also available. Also note it’s possible to program the MatrixCAMs with this devices, however I haven’t been able to locate an update for this. (I’ve looked for this back then when CanalDigitaal shipped those new Smart Cards having the compatibility issues, looking for a bugfix for the freezing problem)
So… it seems all pieces required to do this are available. Will they work together on a Raspberry Pi. And if I obtain a MPEG2 license for the Pi. MPEG is a rather nasty codec due all this license shit, but that’s what all this DVB stuff uses, unfortunately. And Broadcom also has to pay license fees for offering hardware decoding. I don’t agree with all this having to buy a license to unlock a hardware feature, I can understand the reason behind it.
Anyhow, it should be possible, from hardware point of view. From software point of view, the DVB-S2 receiver mentions Linux support. I have no clue about the DVB-T receiver. Also, I don’t know how CCcam or OScam would integrate with XBMC. Well I don’t know anything about XBMC. Hmmm…. I am forgetting something about XBMC. It would also need a remote control, right? DX.com offers remote controls for PCs but are they compatible with XBMC? Well… do I have everything now I need? (Speaking about remote control…. I still can’t find my DVD players remote.)
I’m just wondering, what’s the status of BlueRay on Linux? Is plugging in a BlueRay drive to a Pi an option with XBMC. Well… my USB DVD drive will work given I have the MPEG2 license.
