+- MinimServer Forum (https://forum.minimserver.com)
+-- Forum: MinimServer (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: m3u files for PS Audio Bridge II (/showthread.php?tid=2886)
Pages: 1 2
m3u files for PS Audio Bridge II - peter.rayner - 20-01-2016 02:06
I'm having trouble streaming to my PS Audio DirectStream DAC with
their Bridge II.
Setup: Synology Diskstation 211 running latest DSM software
latest versions of minimserver and minimstreamer
PS Audio Directstream and Bridge II both, I think, also running latest
updates.
Control point is ARCAM Musiclife from an iPhone with IOS 7.
The station in question (ABC ClassicFM) lists both m3u and pls playlists with aac and
mp3 direct urls and I've tried many combinations.
The following m3u file works from my linux machine with
mplayer -ao pulse -playlist classic_fm.m3u
#EXTM3U
#EXTINF:99999,ABC ClassicFM
http://live-radio02.mediahubaustralia.com/2FMW/mp3/
I can install this in a directory on the diskstation and run rescan
from minimwatch. It's picked up as a playlist no problems. When I play
it, the counter increments to suggest it's playing but no sound
emerges.
An alternative of
#EXTM3U
#EXTINF:99999,[*testclassic] ABC ClassicFM
http://live-radio02.mediahubaustralia.com/2FMW/mp3/
Produces the two entries as suggested in the documentation. Playing
"testclassic" does produce sound so the diskstation can reach the
stream. The sound is hopelessly chopped up, I suspect the transcoding
is too much for the diskstation.
The only other information I can give is that the stock mediaserver on
the diskstation would serve shoutcast streams of the same station to
the Bridge but these have recently disappeared and besides I'd prefer
to use minimserver exclusively if I could.
Does anyone have either a solution or further useful tests?
thanks in advance
RE: m3u files for PS Audio Bridge II - simoncn - 20-01-2016 10:39
You need to use the second version with [*testclassic] in the stream name. This routes the stream via MinimStreamer.
I have tried playing this stream without any transcoding and it is working fine for me. You mentioned transcoding in your post. What transcoding are you doing and what happens if you remove your transcoding setting?
RE: m3u files for PS Audio Bridge II - peter.rayner - 21-01-2016 12:02
Still no luck I'm afraid.
The current m3u file looks like:
#EXTM3U
#EXTINF:99999,[*classicfm] ABC ClassicFM
http://live-radio01.mediahubaustralia.com/2FMW/aac/
and the properties look like:
props
.autoUpdate=true
contentDir=/volume1/music
displayName=MinimServer[DiskStation]
http.port=9790
indexTags=Artist, Date, Genre, All Artists, Composer, Conductor, Orchestra
.logFile=minimserver.log
.logLevel=info
mergeFolderAlbums=false
ohnet.debug=Default
ohnet.port=9791
showExtras=true
startupScan=true
stream.converter=ffmpeg
tagCustom=AlbumArtist.displayRole={artist}, Composer.displayRole={artist}
tagFormat=Artist.displayFormat={$artist$orchestra$conductor}
tagOptions=Album.sortTags={Album, Artist}
.updateReminder=1
I get sound but it's badly broken up.
I also tried
stream.transcode=dsf:dopwav,*:wav
which didn't help.
Anything obviously stupid in these settings?
thanks again for a great product
RE: m3u files for PS Audio Bridge II - simoncn - 21-01-2016 12:32
These settings (without stream.transcode) look fine. I tried playing the AAC stream and this works fine for me.
I don't think the problem is likely to be related to the DiskStation. You can check this by going to Resource Monitor in DSM and looking at the CPU utilization while the stream is playing (with broken-up sound). If this figure is less than 80%, there is no problem with the DiskStation.
Please use MinimWatch to show the log window and view log messages when the stream is playing (with broken-up sound). Do you see anything in the log?
RE: m3u files for PS Audio Bridge II - peter.rayner - 22-01-2016 13:12
Here I have to make my first (I hope gentle) complaint.
While almost all the features of the graphical minimwatch are replicated at the console this doesn't appear to be true for logging. I'm totally blind so rely on the console interface. No problem, I can open the minimserver.log file on the diskstation and look at it directly. The default loglevel doesn't seem to give enough information to test the problem. At the moment I can't see a way of changing the loglevel from the console "prop" interface. Can I do this? Alternatively can I hack a configuration file by hand?
thanks again
RE: m3u files for PS Audio Bridge II - simoncn - 22-01-2016 13:52
(22-01-2016 13:12)peter.rayner Wrote: Here I have to make my first (I hope gentle) complaint.
While almost all the features of the graphical minimwatch are replicated at the console this doesn't appear to be true for logging. I'm totally blind so rely on the console interface. No problem, I can open the minimserver.log file on the diskstation and look at it directly. The default loglevel doesn't seem to give enough information to test the problem. At the moment I can't see a way of changing the loglevel from the console "prop" interface. Can I do this? Alternatively can I hack a configuration file by hand?
thanks again
For the request that I made in my last post to look at log messages while the audio is playing, it should not be necessary to change the default logging level. Any error messages would be visible in the log window and the log file when the logging level is set to 'info'. Do you see any messages with the logging level set to info?
If there are no messages at the 'info' level and you want to dig deeper into what is going on, you can set the logging level to 'debug'. You can change the logging level from the console interface by setting the .logLevel property. The output from the 'props' command includes the default setting
.logLevel=info
and you can use the 'prop' command to change this to verbose, debug or trace. Note that the values for this console property are in all lower case (info, verbose, debug and trace) unlike the combo box in the log window which has the first letters capitalised (Info, Verbose, Debug and Trace). I have noticed that the .logLevel property doesn't appear in the list of properties in the User guide and I will correct this oversight soon.
Because of the very large volume of logging output when the logging level is set to debug or trace (and the need to display this in real time for some debugging situations), it isn't practical to send log output to the console. The lack of logging is the only functional difference between the console interface and the graphical interface.
Hacking the configuration file by hand is not recommended and should not be necessary as all valid user settings in this file are accessible via the console interface.
If you come across any other problems when using the console interface, please let me know.
RE: m3u files for PS Audio Bridge II - peter.rayner - 24-01-2016 08:39
Ok, thanks very much for the guidance on extracting logging information. I set .logLevel=debug, restarted and tried the playlist again.
Just to be sure I'm not misleading you, here's the current version of the m3u file.
#EXTM3U
#EXTINF:99999,[*classicfm] ABC ClassicFM
http://live-radio01.mediahubaustralia.com/2FMW/aac/
One intriguing set of messages look like this:
4302:18:50:15.390 Thread-250: ShoutcastFilter: skipping 2289 bytes of metadata at stream offset 33729
4340:18:50:17.379 Thread-250: ShoutcastFilter: skipping 2065 bytes of metadata at stream offset 52402
4353:18:50:19.974 Thread-250: ShoutcastFilter: skipping 4033 bytes of metadata at stream offset 70851
4374:18:50:24.550 Thread-250: ShoutcastFilter: skipping 2321 bytes of metadata at stream offset 107653
and there are a lot of these
Are they normal?
thanks again for continuing to work through this.
RE: m3u files for PS Audio Bridge II - simoncn - 24-01-2016 14:13
(24-01-2016 08:39)peter.rayner Wrote: Ok, thanks very much for the guidance on extracting logging information. I set .logLevel=debug, restarted and tried the playlist again.
Just to be sure I'm not misleading you, here's the current version of the m3u file.
#EXTM3U
#EXTINF:99999,[*classicfm] ABC ClassicFM
http://live-radio01.mediahubaustralia.com/2FMW/aac/
One intriguing set of messages look like this:
4302:18:50:15.390 Thread-250: ShoutcastFilter: skipping 2289 bytes of metadata at stream offset 33729
4340:18:50:17.379 Thread-250: ShoutcastFilter: skipping 2065 bytes of metadata at stream offset 52402
4353:18:50:19.974 Thread-250: ShoutcastFilter: skipping 4033 bytes of metadata at stream offset 70851
4374:18:50:24.550 Thread-250: ShoutcastFilter: skipping 2321 bytes of metadata at stream offset 107653
and there are a lot of these
Are they normal?
thanks again for continuing to work through this.
These messages are normal. A Shoutcast radio stream contains metadata describing what is currently playing. This information needs to be removed by MinimSreamer before passing the audio data to the renderer for playing. This takes a very small amount of CPU processing and I would not expect this processing to overload the CPU in your DS211.
Do you have any other UPnP renderers that you could use to play the stream as a test? This would confirm whether the problem is caused by some issue with the PSAudio Bridge II and DAC or whether it is related to the combination of MinimStreamer and the DS211.
Are you able to check the CPU consumption on the DS211 while the stream is playing? I am not sure whether you can read the graphical display of CPU consumption in the Resource Managger applet in Synology DSM. If not, another option is to login to the DS211 using SSH and run the 'top' command
RE: m3u files for PS Audio Bridge II - peter.rayner - 25-01-2016 11:39
Ok, two more data points.
With a bit of help I was able to test using an iPhone as a renderer, this with the mConnect control point on the same iPhone. The sound was also badly broken up.
Next back to the Bridge ... still badly broken up. Here are the first few lines of top output
top -b -n1
Mem: 102800K used, 15664K free, 0K shrd, 1292K buff, 26980K cached
CPU: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.04 0.02 0.00 1/261 20698
PID PPID USER STAT VSZ %MEM %CPU COMMAND
8973 8969 http S 286m246.9 0.0 /usr/bin/httpd -DHAVE_PHP
8662 1 root S 220m190.0 0.0 /volume1/@appstore/java8/ejdk1.8.0_51/
8922 1 root S 188m162.8 0.0 php-fpm: master process (/etc/php/php-
8944 8922 http S 188m162.8 0.0 php-fpm: pool www
8945 8922 http S 188m162.8 0.0 php-fpm: pool www
6794 1 root S 120m103.9 0.0 /var/packages/MediaServer/target/sbin/
5130 1 root S 103m 89.6 0.0 scemd
7946 1 root S < 81720 68.8 0.0 /var/packages/AudioStation/target/bin/
7932 1 root S < 79668 67.1 0.0 /var/packages/AudioStation/target/sbin
thanks again
RE: m3u files for PS Audio Bridge II - simoncn - 25-01-2016 13:52
(25-01-2016 11:39)peter.rayner Wrote: Ok, two more data points.
With a bit of help I was able to test using an iPhone as a renderer, this with the mConnect control point on the same iPhone. The sound was also badly broken up.
Next back to the Bridge ... still badly broken up. Here are the first few lines of top output
top -b -n1
Mem: 102800K used, 15664K free, 0K shrd, 1292K buff, 26980K cached
CPU: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.04 0.02 0.00 1/261 20698
PID PPID USER STAT VSZ %MEM %CPU COMMAND
8973 8969 http S 286m246.9 0.0 /usr/bin/httpd -DHAVE_PHP
8662 1 root S 220m190.0 0.0 /volume1/@appstore/java8/ejdk1.8.0_51/
8922 1 root S 188m162.8 0.0 php-fpm: master process (/etc/php/php-
8944 8922 http S 188m162.8 0.0 php-fpm: pool www
8945 8922 http S 188m162.8 0.0 php-fpm: pool www
6794 1 root S 120m103.9 0.0 /var/packages/MediaServer/target/sbin/
5130 1 root S 103m 89.6 0.0 scemd
7946 1 root S < 81720 68.8 0.0 /var/packages/AudioStation/target/bin/
7932 1 root S < 79668 67.1 0.0 /var/packages/AudioStation/target/sbin
thanks again
Thanks for this information. The 'top' output shows no CPU load on the Synology. This could be because top refreshes its display every second or so and this output might not have been captured at the time the music was playing.
Can you describe "broken up" a bit more precisely? For example, it is 10 seconds of sound followed by 2 seconds of silence or 0.5 seconds of sound followed by 0.5 seconds of silence?
It would be helpful if you could capture a debug log while the broken-up sound is playing. Please do the following:
1) Restart MinimServer (this clears the log file)
2) Set the logging level to debug
3) Start playing the stream
4) After about 30 seconds of broken-up sound, stop MinimServer
5) Zip the log file and attach the zipped file as a file attachment to a forum post using the New Attachment/Browse and Add Attachment buttons
Many thanks!