# System freeze playing audio on Raspberry Pi B, FreeBSD 11.0



## Egassem Cinatas (Jan 8, 2017)

I am trying to set up an audio player on a Raspberry Pi B with FreeBSD 11.0 Release.  If I understand correctly, audio should be working with 11.0.  `sysctl` output shows the availability of the VCHIQ driver and of a PCM device.  However, when trying to play an audio file, no audio is played and the system freezes indefinitely.  I have tried playing different file formats with `mpg123`, `ogg123` and `out123`, with the same effect.

Does someone have this working?  Is there a package that needs to be installed manually (and is not pulled in by package dependencies)?  I am not very experienced with BSD yet.  I can provide more information but am unsure what would be relevant.


----------



## k.jacker (Jan 8, 2017)

The output you get from `sysctl` does not give you any information about an attached audio driver.
There is no driver or audio device called VCHIQ. VCH stands for virtual channel.

`dmesg | grep pcm` should show you if a driver is attached to your audio device.
I have an usb-audio device attached that uses the uaudio driver. My output looks like this:

```
pcm0: <USB audio> on uaudio0
```

I assume you use the PI's onboard sound? Or is it some kind off addon-card?

Have you read the Handbook?
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sound-setup.html


----------



## Egassem Cinatas (Jan 8, 2017)

Thank you for your reply.  I am trying to use the on-board sound.  My output of `dmesg | grep pcm` is:


```
pcm0: <VCHIQ audio> on vchiq0
```

I think this (and related entries in `sysctl`) means that the audio driver is included in the kernel now.  This may differ from FreeBSD 10.x where I did not see such devices, and forum posts such as Thread 49915 describe separately maintained kernel modules.

Thank you for pointing me to the handbook again - it had slipped my mind a bit while I researched RPi-specific stuff.  /dev/sndstat contains the line:


```
pcm0: <VCHIQ audio> (play) default
```

However, there is no /dev/dsp* device file.  The only potentially sound-related device I can find is /dev/mixer0.  Should /dev/dsp0 or some such exist?  Can one just create it manually, and with which major/minor device IDs?  The sound(4) manual page on the RPi does not mention a VCHIQ audio driver or anything ARM-related.


----------



## k.jacker (Jan 8, 2017)

Hi,
ok your driver seems attached and it is really called VCHQI and your /dev/sndstat is also fine. You shouldn't need any more than that. I cant't find any more information on that driver anywhere, only the old thread you pointed to. The documentation seems out of date.

However, if /dev/mixer0 is the only device, that's it. One stereo output is all you get 
I think your PI simply wouldn't have enough processing power to drive anything more fancy.
So with a simple audio device like yours (and mine too) there are simply no more devices.
You can also check which channels are available and change volumes in the mixer by just typing `mixer`.

The manpages for the audio drivers are usually named after the kernel modules, so maybe man snd_vchiq(4) exists?


----------



## acheron (Jan 9, 2017)

The audio locking was reworked recently, try to update to CURRENT to see if the problem is still there:
https://svnweb.freebsd.org/base/hea...5/bcm2835_audio.c?revision=310636&view=markup


----------



## Egassem Cinatas (Jan 10, 2017)

With 12.0-current-r311461, I can play a single audio file.  When a second playback is started, the system still freezes.  It does not matter if the player is terminated in between or if the same file is played several times in one run.  After the end of the first playback, *starve* is printed several times in bold face (debug output?).  So r311461 is an improvement, but still does not work.


----------



## acheron (Jan 11, 2017)

Can you try to update the firmware? https://github.com/raspberrypi/firmware/tree/master/boot


----------



## Egassem Cinatas (Jan 12, 2017)

I updated the files bootcode.bin, fixup.dat, fixup_cd.dat, start.elf and start_cd.elf.  This only displays a square of rainbow colours on the monitor but does not boot.  I also tried copying fixup_db.dat, fixup_x.dat, start_db.elf and start_x.elf from the repo.  Should I have updated other files in the boot partition for consistency?  Where can I get them?

Why did you suggest a firmware update?  Do you have a conflicting report from someone who has this working?  If so, it might make sense to compare log files.


----------



## acheron (Jan 13, 2017)

I was thinking about this issue: https://github.com/raspberrypi/firmware/issues/696


----------

