Threaded Mode | Linear Mode

PeteManchester · 06-01-2014, 16:36

(06-01-2014 04:18)classical11 Wrote: Hi Pete,

When MediaPlayer is configured with mpd and I'm using Kinsky to play the radio station using this URL, "mmsh://streaming.radionz.co.nz/concert-mbr?MSWWExt=.asf", it works. I'm not sure how you parse that to send it to mpd but it does the trick. Do you use the mmsh prefix to determine this is a Microsoft Media Server (MMS) stream? Or do you just pass it with the mmsh prefix to mpd?

When using the other URL, "http://streaming.radionz.co.nz/concert-mbr", which is an asx file containing this playlist:
[Reference]
Ref1=http://streaming.radionz.co.nz/concert-mbr?MSWMExt=.asf
Ref2=http://103.14.3.137:80/concert-mbr?MSWMExt=.asf

Could you not use the MSWWExt parameter to work out the referenced URLs are also MMS streams because of the ASF container used? Then you could treat them the same as the first ("mmsh://...") URL.

From what I've read on the wiki about MMS,
http://en.wikipedia.org/wiki/Microsoft_Media_Server
if you specify the mms:// or mmsh:// to the the client (WMP in the example on the wiki), it will handle both RTSP and the older MMS protocol. So applying that prefix for ASF containers should hopefully handle both protocols.

Thanks for the info on mplayer. I will experiment with buffering soon.

But if I had a choice I would use mpd because (like you said) I also like the way mpd handles gapless!

(As a side note, I had a lot of trouble initially on my Ubuntu PC getting mpd to play nicely with pulseaudio but it works fine now. On the raspberry pi I just use alsa and never had any problems.)

Cheers,
Ciprian

Hi Ciprian,

I've updated MediaPlayer so that if the ContentType is 'VIDEO/X-MS-ASF' and if the url from the .asx file ends with 'MSWMEXT=.ASF' and begins with 'http' then I replace 'http' with 'mmsh'.

It seems to work and does not impact the existing radio streams so let's try that.

The new mediaplayer is in the beta/builds directory.

I'm still not convinced that is the correct approach though..

In the case of using the URL "http://streaming.radionz.co.nz/concert-mbr"

I get the .asx file which contains

Quote:[Reference]
Ref1=http://streaming.radionz.co.nz/concert-mbr?MSWMExt=.asf
Ref2=http://103.14.3.137:80/concert-mbr?MSWMExt=.asf

But I cannot see anything that suggests the "MSWMExt=.asf" part means I should replace "http://" with "mmsh://"

Quote:Client programs sometimes use a file name extension or a MIME type to determine whether to render a media file as a stream, render the file after a full download, or refuse to render the file at all. If a client program cannot determine how to treat a media file based on the file name extension or the MIME type, it can determine how to treat the file by inspecting the MSWMExt parameter. For example, the client could treat the file as if it had an extension equal to the value of the MSWMExt parameter. For more information about MIME types and file name extensions, see File Name Extensions. For more information about the MSWMExt parameter, see article 236895 in the Microsoft Knowledge Base.

Quote:.asf video/x-ms-asf Legacy content. Typically used to download and play files or to stream content. May contain audio and/or video content. Typically used to download and play files or to stream content.

In the case of using the URL "mmsh://streaming.radionz.co.nz/concert-mbr?MSWWExt=.asf", in my parsing routine I don't recognize that as needing any parsing and so just pass the URL to MPD or MPlayer.

Let me know how that goes and if you find any other radio streams that do not work..

Cheers,

Pete.

classical11 · (This post was last modified: 07-01-2014 07:52 by classical11.)

Hi Pete,

Thanks very much for the change! I tested it and it works.

I think this stream is actually a Windows Media HTTP Streaming Protocol rather than MMS, which vlc refers to as MMSH (or MMS over HTTP). I had a look at it in wireshark and it is indeed going over HTTP.

Quote:But I cannot see anything that suggests the "MSWMExt=.asf" part means I should replace "http://" with "mmsh://"

I am also not sure how you're supposed to determine that from the link in the asx file (i.e. how do you know if it's an MMS, RTSP or MMSH stream - presumably it's one of those 3 given that ASF is a proprietary Microsoft container used for streaming). According to the wiki, if you prefix the URL with "mms://" in Windows Media Player it tries MMS or RTSP first and if those fail, it then tries MMSH. Perhaps mpd supports a similar fallback mechanism? I don't have a true MMS or RTSP radio station to try to see how it behaves. But at least your fix will ensure MMSH streams are supported in MediaPlayer.

On a related topic, there is another type of ASX playlist (XML based), which MediaPlayer does not seem to support. I don't need it for these radio streams because I can use the URL that gives the playlist that you just added support for, but that's just FYI. Here's the URL:
http://www.radionz.co.nz/audio/live/national.asx

And here's the actual ASX XML file:

Code:

<asx version="3.0">

  <author>Radio New Zealand</author>

  <copyright>(C) Radio New Zealand 2014</copyright>

  <banner href="http://www.radionz.co.nz/x/audio-banner-a3c0191d84cc3c7596a3912aa3912fa1.jpg">

    <MoreInfo href="http://www.radionz.co.nz"/>

    <Abstract>More news and audio on Radio New Zealand</Abstract>

  </banner>

<entry>

  <ref href="http://streaming.radionz.co.nz/national-mbr"/>

</entry>

</asx>

Cheers,
Ciprian

simoncn · 09-01-2014, 19:08

(27-11-2013 18:15)simoncn Wrote: Thanks very much! I have emailed Stoner Acoustics with a purchase enquiry. The lack of volume control doesn't concern me because I will be connecting it to powered monitors and I can use the volume controls on the monitors. At some stage I am hoping to add a pre-amp as this would be more convenient for small volume adjustments and would allow me to use multiple inputs.

I've got the Stoner DAC now (there's a story to be told about why it took so long) and I tried to use it as a plug-in replacement for the built-in audio output. The result is that the track appears to play in Kinsky (the time is advancing), but there's no audio.

Here's a section of the log that was produced about the time I started to play the track:

2014-01-09 17:59:03,348 [Thread-4] DEBUG [org.rpi.providers.PrvPlayList] GetNextId: 11
2014-01-09 17:59:03,364 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] MPlayer svn r34540 (Debian), built with gcc-4.6 © 2000-2$
2014-01-09 17:59:03,384 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] mplayer: could not connect to socket
2014-01-09 17:59:03,400 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] mplayer: No such file or directory
2014-01-09 17:59:03,402 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Failed to open LIRC support. You will not be able to use y$
2014-01-09 17:59:03,408 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Playing http://192.168.0.10:9790/minimserver/*/music/music$
2014-01-09 17:59:03,432 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Connecting to server 192.168.0.10[192.168.0.10]: 9790...
2014-01-09 17:59:03,449 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Cache size set to 520 KBytes
2014-01-09 17:59:03,481 [Thread-5] DEBUG [org.rpi.providers.PrvPlayList] Insert After: 11 URI: http://192.168.0.10:9790/minimserv$
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="0$albums$2$9" parentID="0$albums$2" restricted="1"><dc:$
2014-01-09 17:59:03,489 [Thread-5] DEBUG [org.rpi.providers.PrvPlayList] GetNextId: 12
2014-01-09 17:59:03,699 [Thread-2] DEBUG [org.rpi.providers.PrvPlayList] Insert After: 12 URI: http://192.168.0.10:9790/minimserv$
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="0$albums$2$10" parentID="0$albums$2" restricted="1"><dc$
2014-01-09 17:59:03,706 [Thread-2] DEBUG [org.rpi.providers.PrvPlayList] GetNextId: 13
2014-01-09 17:59:03,705 [OR-PL:3] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Buffering
2014-01-09 17:59:03,732 [OR-PL:3] DEBUG [org.rpi.player.PlayManager] SetStatus: Buffering
2014-01-09 17:59:03,764 [OR-PL:3] DEBUG [org.rpi.providers.PrvAVTransport] Status: Buffering
2014-01-09 17:59:03,773 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Cache fill: 11.43% (60860 bytes)
2014-01-09 17:59:03,779 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] libavformat version 53.21.1 (external)
2014-01-09 17:59:03,789 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Mismatching header version 53.19.0
2014-01-09 17:59:03,795 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Audio only file format detected.
2014-01-09 17:59:03,798 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] ==========================================================$
2014-01-09 17:59:03,802 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Opening audio decoder: [pcm] Uncompressed PCM audio decoder
2014-01-09 17:59:03,804 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] AUDIO: 44100 Hz, 2 ch, s24le, 2116.8 kbit/100.00% (ratio: $
2014-01-09 17:59:03,828 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
2014-01-09 17:59:03,831 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] ==========================================================$
2014-01-09 17:59:03,836 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] AO: [pulse] Init failed: Connection refused
2014-01-09 17:59:03,842 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] Failed to initialize audio driver 'pulse'
2014-01-09 17:59:03,901 [OR-PL:3] DEBUG [org.rpi.mplayer.OutputReader] AO: [alsa] 44100Hz 2ch s24le (3 bytes per sample)

Does this provide any clues to what's wrong?

PeteManchester · 09-01-2014, 22:19

Hi Simon,

No that looks pretty standard for mplayer.

Depending on the version of wheezy sometimes some config changes are needed to get the USB DAC to work.

Probably the best test is just to plugin in a pair of headphone/input to amp in the Audio Jack whilst the USB DAC is also plugged in.
If you are still getting audio from the Audio Jack whilst the USB DAC is plugged in the most likely fix will be to modify the /etc/modprobe.d/alsa-base.conf.

The line you should change is:

Quote:# Keep snd-usb-audio from being loaded as first soundcard
options snd-usb-audio index=-2

To be

Quote:# Keep snd-usb-audio from being loaded as first soundcard
#options snd-usb-audio index=-2

Then reboot your raspi and try again.

Let me know if that doesn't work..

Thanks,

Pete.

simoncn · (This post was last modified: 09-01-2014 23:51 by simoncn.)

(09-01-2014 22:19)PeteManchester Wrote:
Quote:# Keep snd-usb-audio from being loaded as first soundcard
#options snd-usb-audio index=-2

Then reboot your raspi and try again.

Let me know if that doesn't work.

Thanks! This change has produced audio from the Stoner DAC, but it is impossible to listen to it for more than few seconds because the audio is interrupted by numerous clicks and pops. I have tried it with the DAC plugged into the Pi directly and also with the DAC plugged into a powered USB hub, and the problem occurs in both cases. Have you experienced this problem with your Stoner DAC? What is the solution?

PeteManchester · 10-01-2014, 10:26

(09-01-2014 23:50)simoncn Wrote:
(09-01-2014 22:19)PeteManchester Wrote:
Quote:# Keep snd-usb-audio from being loaded as first soundcard
#options snd-usb-audio index=-2

Then reboot your raspi and try again.

Let me know if that doesn't work.

Thanks! This change has produced audio from the Stoner DAC, but it is impossible to listen to it for more than few seconds because the audio is interrupted by numerous clicks and pops. I have tried it with the DAC plugged into the Pi directly and also with the DAC plugged into a powered USB hub, and the problem occurs in both cases. Have you experienced this problem with your Stoner DAC? What is the solution?

Hi Simon,

I've not experienced that before, not sure what could be causing that problem.

What colour plastic sleeve does the DAC have?

simoncn · (This post was last modified: 10-01-2014 14:25 by simoncn.)

(10-01-2014 10:26)PeteManchester Wrote: Hi Simon,

I've not experienced that before, not sure what could be causing that problem.

What colour plastic sleeve does the DAC have?

The plastic sleeve is transparent.

I've been doing some experiments and I've found a combination that is sounding very good:

1) The DAC must be plugged into the Pi directly, not into a powered USB hub. When the DAC is plugged into a hub, the audio is broken up and very distorted.

2) The mplayer.conf file must be updated with the setting

ao=alsa:device=hw=0.0

This prevents software resampling of the audio passing through mplayer.

3) MinimServer transcoding should be set to wav24

4) It's best to serve the music from a local instance of MinimServer running on the Pi. When streaming across the network, there are occasional audible minor glitches.

classical11 · 11-01-2014, 03:06

(10-01-2014 14:15)simoncn Wrote:
(10-01-2014 10:26)PeteManchester Wrote: Hi Simon,

I've not experienced that before, not sure what could be causing that problem.

What colour plastic sleeve does the DAC have?

The plastic sleeve is transparent.

I've been doing some experiments and I've found a combination that is sounding very good:

1) The DAC must be plugged into the Pi directly, not into a powered USB hub. When the DAC is plugged into a hub, the audio is broken up and very distorted.

2) The mplayer.conf file must be updated with the setting

ao=alsa:device=hw=0.0

This prevents software resampling of the audio passing through mplayer.

3) MinimServer transcoding should be set to wav24

4) It's best to serve the music from a local instance of MinimServer running on the Pi. When streaming across the network, there are occasional audible minor glitches.

Hi Simon,

Thanks for sharing your observations.

It's interesting that you've had audio glitches when streaming across the network. Were you using Wifi at either end? Do you get glitches when you disable transcoding?

What sort of distortions do you hear when you plug in your DAC into the powered USB hub? Are they very noticeable? Could they be related to the hub you are using?

I haven't had any audio glitches in my setup but there are a few differences to yours. I am using the same DAC (Stoner Acoustics UD110v2) connected to a powered USB hub. However I'm using mpd for playback. Another difference is that I'm not doing any transcoding on the MinimServer end. My files are 16 bit flac and mp3.

I can't hear any noticeable difference if I plug the DAC in the Raspberry Pi or in the USB hub.

The MediaPlayer renderer is running on a Raspberry pi with Raspbian hf. On another Raspberry Pi I have MinimServer and it's reading the library off a USB hard drive (connected to a powered USB hub). Both are connected to the network via wired Ethernet.

A few observations:

- MinimServer has been rock solid for the last month or so. I only restart it occasionally to apply updates.

- I don't hear any glitches even when I stream to 3 devices at the same time (2xRaspberry Pis and a Linux PC, all running MediaPlayer, all through wired Ethernet)

- mpd must be configured in /etc/mpd.conf to use the correct ALSA device for the USB DAC:

Code:

audio_output {

        type            "alsa"

        name            "My ALSA Device"

        device          "hw:1,0"        # Use the right device here

        auto_resample "no"      # disable resampling

}

- Also, set the mixer type to "software" in order to be able to configure the volume, as Pete described in another post:

Code:

mixer_type                      "software"

- I initially had one of the Raspberry Pis running the renderer connected using Wifi but the Wifi drivers were flaky causing it to lose connection every 1-2 days

- MediaPlayer and mpd work very nicely. gapless works flawlessly.

- I am very satisfied with the sound coming out of the DAC when playing standard definition 16 bit flac files (but I don't have a high end system like a Linn for comparison so this is obviously pretty subjective). I would however like to experiment with transcoding to wav24 at some point.

- I am using BubbleUPnP (and sometimes BubbleDS) for the control points.

Cheers,
Ciprian

simoncn · 11-01-2014, 19:01

(11-01-2014 03:06)classical11 Wrote: Hi Simon,

Thanks for sharing your observations.

Thank you for sharing yours!

Quote:It's interesting that you've had audio glitches when streaming across the network. Were you using Wifi at either end? Do you get glitches when you disable transcoding?

There is no wi-fi involved. I haven't done a detailed comparison of transcoding vs. non-transcoding. The non-transcoding case isn't of much interest to me because I prefer the sound with transcoding enabled, based on my experience so far.

Quote:What sort of distortions do you hear when you plug in your DAC into the powered USB hub? Are they very noticeable? Could they be related to the hub you are using?

The sound is very low-pitched and appears to play more slowly, and is also "chopped up". I am using the powered USB hub supplied by NewIT in the UK. This problem occurs without transcoding enabled.

Quote:
I haven't had any audio glitches in my setup but there are a few differences to yours. I am using the same DAC (Stoner Acoustics UD110v2) connected to a powered USB hub. However I'm using mpd for playback. Another difference is that I'm not doing any transcoding on the MinimServer end. My files are 16 bit flac and mp3.

I'm unable to use mpd because I haven't been able to make it play a WAV stream. There was a discussion about this some time ago on this thread.

Quote:I can't hear any noticeable difference if I plug the DAC in the Raspberry Pi or in the USB hub.

The MediaPlayer renderer is running on a Raspberry pi with Raspbian hf. On another Raspberry Pi I have MinimServer and it's reading the library off a USB hard drive (connected to a powered USB hub). Both are connected to the network via wired Ethernet.

A few observations:

- MinimServer has been rock solid for the last month or so. I only restart it occasionally to apply updates.

- I don't hear any glitches even when I stream to 3 devices at the same time (2xRaspberry Pis and a Linux PC, all running MediaPlayer, all through wired Ethernet)

That's interesting. It might be because you are using 16-bit non-transcoded streams, or it might be a difference between mpd and mplayer.

Quote:- mpd must be configured in /etc/mpd.conf to use the correct ALSA device for the USB DAC:

Code:

audio_output { type "alsa" name "My ALSA Device" device "hw:1,0" # Use the right device here auto_resample "no" # disable resampling }

Perhaps this is the cause of my sound distortion problem when using the USB hub. I am currently using 0.0 as the device. Should I be using 1,0 instead? How can I find the correct number? Is it significant whether the numbers are separated by a period or a comma?

Quote:- Also, set the mixer type to "software" in order to be able to configure the volume, as Pete described in another post:

Code:

mixer_type "software"

I don't need to do this, as I can use the volume controls on my powered speakers. In general I have found that doing less processing in the audio path improves the sound.

Quote:- I initially had one of the Raspberry Pis running the renderer connected using Wifi but the Wifi drivers were flaky causing it to lose connection every 1-2 days

- MediaPlayer and mpd work very nicely. gapless works flawlessly.

I would like to try to using mpd if I can get it running with WAV streams. Do you have any suggestions for how to do this?

Quote:- I am very satisfied with the sound coming out of the DAC when playing standard definition 16 bit flac files (but I don't have a high end system like a Linn for comparison so this is obviously pretty subjective). I would however like to experiment with transcoding to wav24 at some point.

- I am using BubbleUPnP (and sometimes BubbleDS) for the control points.

Cheers,
Ciprian

I have found a noticeable improvement with wav24 transcoding of 16-bit FLAC files. With wav16 transcoding of 16-bit FLAC files, it's hard to be sure whether there's an improvement.

classical11 · 12-01-2014, 06:28

Quote:The sound is very low-pitched and appears to play more slowly, and is also "chopped up". I am using the powered USB hub supplied by NewIT in the UK. This problem occurs without transcoding enabled.

I am using a Belkin 7 port powered hub:
http://www.amazon.com/Belkin-USB-2-0-7-P...rt+usb+hub

It comes with a 5V, 2.5A power supply.

This may be a red herring but I noticed that your hub's power supply can only give 1A so perhaps it's a power issue?

Do you feed power from the hub back into the Raspberry Pi (via a USB port on the hub)? Or do you power the Raspberry Pi independently? Do you have other devices plugged into your USB hub?

If the DAC is the only device and you power the Raspberry Pi independently, then this can't be it.

If you have other devices plugged into the hub maybe the DAC is not getting enough power from the hub.

I've read various reports from Raspberry Pi users complaining of system stability issues when using low powered hubs (or no hub at all).

Quote:Perhaps this is the cause of my sound distortion problem when using the USB hub. I am currently using 0.0 as the device. Should I be using 1,0 instead? How can I find the correct number? Is it significant whether the numbers are separated by a period or a comma?

I believe the format you are using is correct for mplayer.

The standard ALSA format for a device is hw:<card#>,<subdevice#>. mpd uses the standard ALSA format as is. mplayer requires some minor adjustments as described in the manual page:

Code:

device=<device>

                      Sets the device name.  Replace any ',' with '.' and any ':' with '=' in the ALSA device name.  For hwac3 output via  S/PDIF,  use

                      an "iec958" or "spdif" device, unless you really know how to set it correctly.

You can list your ALSA playback devices with "aplay -l". In my case, I get this:

Code:

pi@pi1 ~ $ aplay -l

**** List of PLAYBACK Hardware Devices ****

card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]

  Subdevices: 8/8

  Subdevice #0: subdevice #0

  Subdevice #1: subdevice #1

  Subdevice #2: subdevice #2

  Subdevice #3: subdevice #3

  Subdevice #4: subdevice #4

  Subdevice #5: subdevice #5

  Subdevice #6: subdevice #6

  Subdevice #7: subdevice #7

card 1: UD110v2 [UD110v2], device 0: USB Audio [USB Audio]

  Subdevices: 1/1

  Subdevice #0: subdevice #0

I am using 1,0 because the card ID of the DAC is 1. It's strange that it is 0 in your case because I would expect the built in analog card to always be the first. But I would have thought that you'd get absolutely no sound at all if you used an incorrect card id.

Quote:I would like to try to using mpd if I can get it running with WAV streams. Do you have any suggestions for how to do this?

I have not experimented with this yet and I am not very familiar with mpd. I will try it at some point and if I have any luck with it I will post my findings here.

Quote:I have found a noticeable improvement with wav24 transcoding of 16-bit FLAC files. With wav16 transcoding of 16-bit FLAC files, it's hard to be sure whether there's an improvement.

Looking forward to trying out transcoding to wav24 (if I can figure out how to stream it to mpd).