No Sound on Raspberry Pi

So far I’ve been unable to find an answer to this problem on the forums but I’m hoping someone can help; I have a RPi Model B rev 2 which I got for Christmas. As well as installing Raspbian Wheezy, I’ve been using riscos-2012-11-01-RC6 (pre-loaded on an SD card from ROOL) and it works very well indeed, except I cannot get the sound to work under RISC OS. Video output is via an adapter to an old VGA monitor, so I’m trying to get sound out of the audio jack but so far I’ve had no success. I’ve managed to get sound working from the jack under Linux, so I don’t think it’s a hardware problem. I’ve checked the Sound part of Configuration and it’s not muted. I’ve also tried adding “hdmi_drive=1” to the the config/txt file and when that didn’t work I tried “hdmi_drive=2” but again to no avail. I’m afraid I’ve now reached the limit of my technical knowledge – can anyone offer a possible solution to this lack of sound problem?

Mike, I’ve just added a message to the sound thread on the R-Pi RISCOS forum, saying that I was having the same trouble as you – no sound.

I my case I tried multiple R-Pi boards, multiple SD card images and multiple headphone/speaker setups, but they all exhibited the same mute sound. Weird, as these boards/cards all had sound working perfectly a week or two back.

Then it struck me that the one change I’d made that was now common to all these setups was to try out an HDMI to VGA adapter feeding into the VGA side of my monitor. This instead of the previous direct HDMI to DVI connection I was using before. So I reinstated the direct HDMI cable and bingo – sound reappeared at the headphone socket!

I’m not sure why a VGA adapter affects sound output through the R-Pi headphone socket under Risc OS but not under linux. Possibly the only solution to your problem may be to acquire a DVI-D monitor for your R-Pi.

-Neil F.

Thanks for your reply Neil, much appreciated. I think you may well be right about the HDMI to VGA converter (or its presence) somehow disabling sound from the jack – just tried composite video on another monitor and sound works fine. Unfortunately the picture quality is so awful as to be nearly unusable. Also I can’t really justify the expense of a more modern monitor right now, so I’ll have to continue to look for another solution.

A bit more info which I hope might throw more light on the matter; initially sound didn’t work through the jack under Linux either but following a tip I read on the rasberrypi.org forums I added “sudo amixer cset numid=3 1” to /etc/rc.local, so that the command was executed before startx, ie before the operating system was booted up. My technical knowledge is pretty much near zero but could something similar be needed for RISC OS on RPi?

Strictly speaking, it isn’t the presence of a VGA adapter that causes the problem, it’s the absence of a suitable signal on one of the lines in the HDMI socket – a signal normally supplied by the HDMI or DVI monitor at the other end of the cable.

I’m not familiar with how that works, but if it is simply a line pulled high or low, it ought to be possible to simulate that by hacking the VGA adapter or cable (or even a track on the R-Pi board itself).

On the other hand, it would be a lot simpler if we could just have a config.txt file setting that keeps RISC OS sound permanently output via the headphone socket. Perhaps there’s an obscure setting already available but it’s just not widely known? Anyone know of one?

No sound from my RasPi issues from either the audio socket or via the HDMI cable. Any thoughts?

There is no HDMI to VGA adaptor involved in this case – the HDMI goes straight to the telly!

DVI moitors are available all over the place for $40USD to $50USD.

[citation needed] ;-)

This isn’t one of those cases where “monitor costs pennies but the postage will hurt” is it?

Stewart: forgive me if you already know this but have you set hdmi_drive=2 in the config.txt file to enable sound through HDMI?

Well I was aware of this but as the context was always that of an HDMI to VGA adaptor, I thought it only applied to that and ignored it. However, I gave it a go last night, and indeed, it cured the sound problem but gave rise to another! The desktop now overshot the screen on all sides; so I investigated further: it seems that you can use ‘overscan_left’, ‘overscan_right’ … etc statements to correct this, but it’s a matter of trial + error. And then, when I managed to get it almost right, I found that the mouse pointer was being seen by the ’puter considerably further to the right of where it was displayed on screen. So the whole affair is beginning to look like a bad joke.

And then, when I managed to get it almost right, I found that the mouse pointer was being seen by the ’puter considerably further to the right of where it was displayed on screen. So the whole affair is beginning to look like a bad joke.

How old is the ROM you’re using? That bug was fixed a while ago (but perhaps not for any of the official/stable releases, I’m not sure)

UPDATE: Adding “hdmi_group=1” as well as " hdmi_drive=2" to the CONFIG.TX file has cured both the sound problem and the screen overshoot, but given rise to a new problem! Whenever the mouse approaches a screen edge or whenever a window is raised, the screen brightness, esp. on the rhs side changes – it increases. So more experiments are in order.

How old is the ROM you’re using? That bug was fixed a while ago …

Good point! I’m not sure but I’ll try the latest + report back.

I’ll try the latest + report back

Now it may have been a bettr idea to download just the ROM in NetSurf on RISC OS from this site (ROOL) and go into $.!Boot.Loader rename the old RISCOS/IMG to something else copy the new ROM in and rename it to RISCOS/IMG then reboot.

No no no! That is an absolutely terrible idea and will probably brick your card. $.!Boot.Loader is the magic FAT32 formatted directory which the Pi sees when it boots up, and is cunningly arranged so that RISC OS thinks it’s part of the FileCore partition, but if you attempt to write to it as if it actually is one then you’ll break it. Overwriting the file will probably work, due to implementation-level details of FileCore, but deleting it is right out.

There’s a reason the distribution comes as an SD card image! Exactly how the filesystem is arranged at the sector level is surprisingly important.

The current image from the RPi site does fit on a 2GB card no trouble

The capacity of my cards is reported as being between 1.82 – 1.84GB, whereas the disk .img is ~2.32GB!

Ah, yes, riscos-2012-11-01-RC6 – the one you refer to /will fit/ but the one I d/l from ROOL is as described above, and will not fit. Is a 2GB card obligatory or can we use a 4G?

I modify my boot partition this way all the time.

… and so do I. I regularly update the ROM image this way. I made the (perhaps naive) assumption that the Boot.Loader was there to be used. I have also updated one of the system files that way.

Did not know that ROOL hosted a full SD image for the RPi

Quite right – they don’t – it’s me that’s going senile. I was mistaking the ROM image for the disk image – idiot!

That may have been true on older images, though at least with the current image, the $.!Boot.Loader FILE is a FA32 DOSFS IMAGE FILE SYSTEM mapped to the blocks that coinside with the fat32 partition

My mistake, I forgot it was a file. My point still stands, though – FileCore doesn’t know that it’s important for that specific file to be mapped into that specific place. If you give it an opportunity to change the mapping, it will. Therefore, deleting it is a bad idea, because any replacement file is likely to be mapped somewhere else. AIUI, the most likely scenario is that the Pi will carry on booting, reading the old loader from the space in which it used to be, until FileCore decides it’s time to reuse the space for something else and stomps all over the remains.

Dragging a new file on top of it (as you’re doing) will probably work, again due to the way FileCore is implemented (preferring to reuse a file’s existing mapping than go to the trouble of allocating a new one), although if the replacement is significantly larger than the original file then that may be another matter altogether.

And writing inside of a Image filing system will not change the number of blocks allocated to the image filing system…

That surely depends on ths FS. For example, SparkFS implements an Image Filing system for zip files, but you can copy files into the zip … and the zip expands!

Exactly. I was just pointing out that it does not apply to all Image FS.

To return momentarily to the business of no sound, I think the problem is semi-solved. Following a couple of articles posted by Nick Brown (http://www.riscosopen.org/forum/forums/11/topics/1579) I took a leaf from his book and bought a 1080 Ultimate Converter on ebay and now under RISC OS I’m able to get sound from the converter’s audio jack. It took some trial & error to get the picture aspect ratio and quality right but I sort of got there in the end.

However, each time I boot up the RPI from cold the aspect ratio isn’t right and the picture is sort of squashed horizontally. A reboot, though, results in a brief message coming up on the monitor, saying “auto adjusting” and then the picture aspect is fine.

What’s more puzzling is that when I boot into Raspbian Wheezy there’s no sound from the adapter audio jack; I have to plug it into the Pi’s own audio jack to get any audio.

I’ve tried two different VGA monitors and the result is the same. It’s probably down to my lack of knowledge in this area – I can live with unplugging/replugging the audio jack but I’d like to get the picture right; I have in the config file:

hdmi_drive=2
hdmi_group=2
hdmi_mode=35

Can anybody more knowledgeable suggest what I’m doing wrong so I can have sound without then having to double boot to get the picture right?

Does your monitor tell you what resolution it is receiving from the computer? This may be different from what RISC OS is doing and (also) different from its native resolution. Check this after first and second boot and this may help explain it.

The config settings should force the Pi GPU to a particular output resolution every time you boot, including the first [with no config settings, it listens to the monitor and tires to identify its preferred resolution]. RISC OS may produce a different resolution which is independent of the config settings and, if so, the GPU will stretch this to fit its output resolution. If the GPU output does not match the monitor’s native resolution, then the monitor will stretch/shrink it to fit.

From a cold boot under RISC OS the resolution is 1280×720. A reboot results in 1280×960 (I now use Mode=32 as, to my eye, it gives a crisper picture and better aspect ratio on that particular monitor, though mode=35 seems to suit Linux better). Cold booting into Linux results in 1184×624, which seems a bit odd to me, then a sudo reboot gives 1280×1024. For some reason I couldn’t get the 1080 Ultimate Converter to display anything with no settings in the config file so I temporarily went back to my Cable Matters converter, without any config settings, which booted straight into 1280×1024 from a cold boot, but no audio of course. Does this information help to track down the cause of these anomalies?

What resolution? GPU or RISC OS or monitor?