Issue 6

When trying to compile sc2mpd on a raspberry pi with Archlinux arm the compilation of the openhome libraries, using ohbuild.sh fails with an error on not finding the correct platform. In the openhome Makefile the check is done with: gcc -dumpmachine. The output seems to differ between different gcc versions on arm (like used in Raspbian or Archlinux). Currently the output of gcc -dumpmachine on Archlinux is (pi2 and pi3 64 bit): armv7l-unknown-linux-gnueabihf aarch64-unknown-linux-gnu

In the current git version of Openhome/ohNet this seems to be (partially) solved with a better check on archictecture: + ifneq (,$(findstring linux-gnueabihf,$(gcc_machine))) + detected_openhome_architecture = armhf

But the ohbuild.sh script seems to checkout an older version of theh Openhome libraries.

I just pushed an update to ohbuild.sh, please let me know how it works for you. I don’t even understand how the previous version could work at all (the patches had to fail every time). Probably because Unknown is actually ok as an arch name when building the openhome libs for sc2mpd…

I probably need to update the openhome version I use, but, by experience, not all states of the Linn github repos are actually working, so it would be quite a lot of work to update the scripts and make sure that the result is good. As long as no problems are reported with upmpdcli/sc2mpd, I’d rather stay with the current version.

The new ohbuild.sh is working perfectly now. So this issue can be closed. Thanks.

One thing I noticed is that you can choose a songcast receiver with upplay or linn kinsky, but not with kazoo. In kazoo you can add a receiver in a group by selecting a room and click on the + sign. But the list of receivers to group with the room is empty. I’m not sure if that’s fixed with a more recent version of openhome or an other abnormally of kazoo.

Thanks. I’ll take a look at the Kazoo issue. This should not be dependant on the OpenHome libs version, because they are used only for the Songcast audio protocol itself. Everything dealing with listing/starting/grouping Senders and Receivers is done through UPnP (so going through libupnpp on my side), probably there is some action missing or a parameter with a wrong value somewhere.

I had a look at Kazoo, and I don’t see any + sign at all. Actually, I don’t see any songcast function at all: how do you get to this ? I have a Linn Sneaky DS on the network, and a number of songcast-capable upmpdcli instances, and I can mix and match as I want with bubble or upplay, but I see nothing in Kazoo, not even an empty list. What version are you using ?

I’m using the IOS version of Kazoo. If I’m selecting a room I have the option to group the room with other rooms by clicking on the + sign. See attachments.  

Thanks ! I updated my Kazoo copy, and I now get a similar screen on Windows.

However, the only thing I can group stuff with is the actuall Linn DS, the upmpdcli instances do not appear.

There must be some difference which prevents Kazoo from using them.

There is at least one difference in that the Sender in a Linn device is a service inside the device, while it is a service inside a separate device in the case of upmpdcli.

There is probably not much I can do, only the Kazoo programmer could tell what’s happening.

That’s a pity, but thanks for looking! At the moment I have problems to even get songcast to work with applay and Kinsky but that’s probably a configuration issue on my side…

From my recent testing, as long as sc2mpd is installed and the upmpdcli configurations has parameters scplaymethod=alsa an scalsadevice=something listed by aplay -L, things just work. What problems are you seeing ?

I don’t have access to the upmpdcli devices now, so can’t test. But I’m basically don’t get any sound if I connect the receivers to the sender. In upplay or kinsky I select as output "pl-to-songcast" to enable the sender and connect the receivers to this sender with the upplay songcast tool. I do see an mpd2sc and sc2mpd process on the sender/receiver if I look with "ps aux". I also see a sc2mpd process on the receiver. So that part seems to work OK. But I don’t get any sound, so I expect there is something wrong in my selecting of the "scalsadevice". aplay -L lists "default" as my soundcard. So on both upmpdcli systems I have the following in my upmpdcli configuration: scplaymethod=alsa scalsadevice=default

espakman writes: > I don’t have access to the upmpdcli devices now, so can’t test. But I’m > basically don’t get any sound if I connect the receivers to the sender. In > upplay or kinsky I select as output "pl-to-songcast" to enable the sender and > connect the receivers to this sender with the upplay songcast tool. I do see an > mpd2sc and sc2mpd process on the sender/receiver if I look with "ps aux". I > also see a sc2mpd process on the receiver. So that part seems to work OK. > But I don’t get any sound, so I expect there is something wrong in my selecting > of the "scalsadevice". > aplay -L lists "default" as my soundcard. So on both upmpdcli systems I have > the following in my upmpdcli configuration: > scplaymethod=alsa > scalsadevice=default

I was never bold enough to take a plunge in the alsa docs, so I understand little about alsa. But I usually use the complete line from aplay -L as parameter, including the part after the colon, such as, in my case:

I’m not sure if it makes any sense but it works for me…

I just tried with: scplaymethod = alsa svalsadevice = default:CARD=sndrpihifiberry

But still no luck

# aplay -L null Discard all samples (playback) or generate zero samples (capture) default:CARD=sndrpihifiberry snd_rpi_hifiberry_dacplus, Default Audio Device sysdefault:CARD=sndrpihifiberry snd_rpi_hifiberry_dacplus, Default Audio Device

# cat /proc/asound/card0/pcm0p/sub0/hw_params closed

But the songcast sender and receiver seems to work.

# ps aux | grep mpd mpd 1020 0.0 1.4 106344 13864 ? S<sl Jan08 1:18 /usr/bin/mpd --no-daemon upmpdcli 5220 0.3 0.9 149180 9136 ? Ssl 19:56 0:02 /usr/bin/upmpdcli -c /etc/upmpdcli.conf upmpdcli 5240 0.0 0.8 12656 8176 ? S 19:56 0:00 python /usr/sbin/scmakempdsender -p 6700 -f Archphile upmpdcli 5242 6.5 1.4 108444 13228 ? Sl 19:56 0:59 mpd --no-daemon --stderr /tmp/tmpl8aHfA upmpdcli 5246 0.2 0.4 21860 4144 ? Sl 19:56 0:02 mpd2sc -f /tmp/tmplqFMdh.fifo -A 44100:16:2:1 -u urn:uuid:68cfc171-194a-5043-a450-3ff4718a47b5 -n Archphile UxSender upmpdcli 5704 0.2 0.8 49176 8124 ? Sl 20:11 0:00 /usr/sbin/sc2mpd -d -u ohz://239.255.255.250:51972/urn:uuid:68cfc171-194a-5043-a450-3ff4718a47b5 -c /etc/upmpdcli.conf

svalsadevice should of course read scalsadevice

Did you try to activate the sc2mpd log to see if has anything to say?

Also maybe use one machine in sender/receiver mode and another for receiver experimentation if you can.

When I configure sclogfilename = /var/log/sc2mpd.log scloglevel = 5 no logfile is created…..

on my second machine in receiver state amd my first one as sender/receiver: # aplay -L null Discard all samples (playback) or generate zero samples (capture) default:CARD=II Music Streamer II, USB Audio Default Audio Device

Upmpdcli.conf: scplaymethod = alsa scalsadevice = default:CARD=II

# ps aux | grep mpd nobody 266 0.0 0.3 5892 3020 ? Ss Jan08 1:14 /usr/bin/ympd --user nobody --webport 80 --host localhost --port 6600 mpd 460 0.0 1.4 106352 13760 ? S<sl Jan08 1:58 /usr/bin/mpd --no-daemon upmpdcli 3452 0.1 0.9 124496 8936 ? Ssl 21:36 0:00 /usr/bin/upmpdcli -c /etc/upmpdcli.conf upmpdcli 3464 0.0 0.8 130820 8320 ? Sl 21:36 0:00 /usr/bin/upmpdcli -m 2 -c /etc/upmpdcli.conf upmpdcli 3480 0.0 0.8 49176 8204 ? Sl 21:38 0:00 /usr/sbin/sc2mpd -d -u ohz://239.255.255.250:51972/urn:uuid:68cfc171-194a-5043-a450-3ff4718a47b5 -c /etc/upmpdcli.conf

# cat /proc/asound/card0/pcm0p/sub0/hw_params closed

So no sound either….

Are you sure that the process has permissions to write to /var/log ? It should not actually.

You can stop sc2mpd and start it on the command line by the way (unset sclogfilename so that the messages go to stderr). Maybe we’ll see something this way:

Below the output of the receiver. For me it looks like songcast is working but there is some problem with alsa… # /usr/sbin/sc2mpd -d -u ohz://239.255.255.250:51972/urn:uuid:68cfc171-194a-5043-a450-3ff4718a47b5 -c /etc/upmpdcli.conf :3:sc2src/sc2mpd.cpp:536::scmpdcli: using subnet 192.168.0.0 CONNECTED LATENCY 100 BEGIN ON 68 GOT 69 GOT 70 GOT 67 END BEGIN ON 613 GOT 612 END BEGIN ON 1716 GOT 1715 END BEGIN ON 3445 GOT 3444 END BEGIN ON 3493 GOT 3492 END BEGIN ON 3860 GOT 3859 END BEGIN ON 4228 REQUEST RESEND 4227 GOT 4227 END BEGIN ON 4404 GOT 4403 END

Yes, I don’t see the periodic messages about songcast synchronisation (in upmpdcli log format) that we should see if the alsa output was working. I am going to give it a try on my arch copy.

Hi,

I got it working on arch, but with a bit of trouble, and I’m not absolutely sure what did it. I think that it was adding the upmpdcli user to group audio (sc2mpd runs as upmpdcli). I’m not sure why a permission error did not trigger a log message though.

Anyway, data on my now working system (originally runeaudio, but since updated to current arch):

----` runeaudio$ aplay -L null Discard all samples (playback) or generate zero samples (capture) sysdefault:CARD=sndrpihifiberry snd_rpi_hifiberry_dacplus, Default Audio Device

----`

----` runeaudio$ cat /etc/upmpdcli.conf # Displayed "Friendly Name" for the UPnP Media Renderer friendlyname = RuneAudioUPnP

# icon iconpath = /usr/share/upmpdcli/runeaudio.png

# Log file name. Defaults to stderr. This can also be specified as # -d logfilename #logfilename = /var/log/runeaudio/upmpdcli.log

# Log level. 0-4. Can also be specified as -l loglevel. loglevel = 4

scplaymethod = alsa scalsadevice = sysdefault:CARD=sndrpihifiberry scloglevel=4 #sclogfilename=/tmp/sc2mpd.log

----`

audio output in /etc/mpd.conf:

----` audio_output { name "hifiberry dacplus" type "alsa" device "hw:0,0" mixer_control "Digital" mixer_type "hardware" mixer_device "hw:0" auto_resample "no" auto_format "no" enabled "yes" }

----`

Adding the upmpdcli user to the audio group indeed solved the problem. The archlinux package doesn’t set that correctly… thanks a million, it was really driving me crazy :)

I need to check why this did not trigger any kind of error message, this is weird and very inconvenient. I’m opening another issue on this.