• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

Amanero Isolator/Reclocker GB

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Member
Joined 2010
Paid Member
Acko,

As miero suggested I try few traces at different frequencies including the test files from miero and all the traces are playing well.

So, in the same time I test the S03 that is working. :up:

I have listened very few traces just for the troubleshooting but the first impression is that the BBB and the S03 is a very good pairs.

Nice job acko, as usual :)

Regards,
Enrico

PS: The next exciting step will be the NMR with the S03
 
Member
Joined 2010
Paid Member
miero, I have upmpdcli installed on top of your botic software and it works perfectly.

Ray

Hi Ray,

Today I try to re-write the SD card from scratch to see if the new installation can solve the problem but I make it worse :(

Yesterday, following the upmpdcli instruction in the website, everything goes as expected. I created the file /etc/apt/sources.list.d/upmpdcli.list with the two lines required and when I do "sudo apt-get update" the BBB make the updates without any issue.

Today the same file with the same two lines give me the following:
root@bbb:~# sudo apt-get update
Get:1 Debian -- Security Information wheezy/updates Release.gpg [836 B]
Hit Debian -- Security Information wheezy/updates Release
E: Release file for http://security.debian.org/dists/wheezy/updates/Release is expired (invalid since 248d 8h 41min 32s). Updates for this repository will not be applied.


Now I have really no idea how can proceed with the upmpdcli.

I hope that somebody here can give me some advice.

Thanks and Regards,
Enrico
 
Acko,

As miero suggested I try few traces at different frequencies including the test files from miero and all the traces are playing well.

So, in the same time I test the S03 that is working. :up:

I have listened very few traces just for the troubleshooting but the first impression is that the BBB and the S03 is a very good pairs.

Nice job acko, as usual :)

Regards,
Enrico

PS: The next exciting step will be the NMR with the S03

Great to hear of your progress and many thanks to those who helped you!
The problem with upmpdcli is surprising given Ray and Chanh are using it in different setups without problems.

I am not sure this would help but try installing Botic etc onto the eMMC of BBB instead. Instructions from Miero:

Flashing image on eMMC
The eMMC of BBB can be flashed with this "Botic distribution" using following steps:
(( backup all important ))
(( boot from SD card ))
root@bbb:~# /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh
...
...
... (after 5 minutes of copying data)
...
This script has now completed it's task
-----------------------------
Note: Actually unpower the board, a reset [sudo reboot] is not enough.
-----------------------------
root@bbb:~# poweroff
((wait until it powers down))
((remove SD card))
((power it on))
.... voilà ... and if you are lucky as me ... you have booted from eMMC :)
 
Hi Enrico,

I do have a clitch/crack sound every time a track is changing. It lasts less then fraction of a second, nothing to be concerning.
1. I started with a fresh image from Miero.
2. Install upmpdcli with instructions provided as Jean-Lious web site. When you do "nano /etc/apt/..../upmpdcli.list" ensure all words are precise and accurate. It is easy to have typo, for me anyway. Also ensure the two lines are typo free before save and exist.
3. Once exist, type "apt-get update & apt-get upgrade"
4. Once the above are done, typically take 10mins pending your isp's speed. Type "apt-get install upmpdcli"
5. Type reboot once it is done.

You can further tweak static ip or dynamic from "nano /etc/network/interfaces" personally I prefer static ip.

From here on it should be working fine.
 
Member
Joined 2010
Paid Member
Great to hear of your progress and many thanks to those who helped you!
The problem with upmpdcli is surprising given Ray and Chanh are using it in different setups without problems.

I am not sure this would help but try installing Botic etc onto the eMMC of BBB instead. Instructions from Miero:

Thanks Acko and all of you guys that are supporting me with the BBB.

Maybe I wrong but I don't think that the installation in the eMMC will solve the problem. FRom the tests done yesterday it is clear that the miero botic is working perfecly... the problem is the upmpdcli

Anyway, I am stacked now with the upmpdcli. The update instruction that yesterday was done without problems today doesn't work more.

Thanks and Best Regards,
Enrico
 
Member
Joined 2010
Paid Member
Member
Joined 2010
Paid Member
emyeuoi: probably caused by unsynchronized time.... try to execute following command first:
ntpdate pool.ntp.org

preparation of new image with included upmpdcli is in progress ... in 2-3 days
http://www.diyaudio.com/forums/members/emyeuoi.html

GREAT!!!... After the command above I can run the dpmpdcli file! THANKS miero!!!

The BBB is now the renderer for the BubbleUPnP BUT with the same glitches and pops :(

I know that is a upmpdcli problem but maybe you have some magic command as above? :D

Thanks again miero for your awesome support

All the Best,
Enrico
 
Member
Joined 2010
Paid Member
Jean-Francois from the upmpdcli website kindly reply to my email where I explained the problem of my BBB and asked for some help.

This is a part of his reply that I think should be interesting for everybody:

Also I had a look at the BBB forum thread, and it seems that people have
cracks when switching tracks when upmpdcli is used. This is not
normal. What you should know is that upmpdcli does not touch the audio data
at all, only URLs, but when it is used, MPD fetches the audio data through
HTTP instead of reading local files, and this is what causes the
differences. In the past I have seen this kind of problem solved by
increasing the audio_buffer_size parameter inside mpd.conf.


I already reply to him that increasing the "buffer size" or the "buffer before play" doesn't solve the issue.

As soon I get an answer I will post.

Regards,
Enrico
 
Jean-Francois from the upmpdcli website kindly reply to my email where I explained the problem of my BBB and asked for some help.

This is a part of his reply that I think should be interesting for everybody:

Also I had a look at the BBB forum thread, and it seems that people have
cracks when switching tracks when upmpdcli is used. This is not
normal. What you should know is that upmpdcli does not touch the audio data
at all, only URLs, but when it is used, MPD fetches the audio data through
HTTP instead of reading local files, and this is what causes the
differences. In the past I have seen this kind of problem solved by
increasing the audio_buffer_size parameter inside mpd.conf.


I already reply to him that increasing the "buffer size" or the "buffer before play" doesn't solve the issue.

As soon I get an answer I will post.

Regards,
Enrico

Hi,

As I (Jean-Francois) am subscribed to the diyaudio forums, I think that I could add a few words of explanations.

First, to confirm: it is not normal at all to have noises or cracks or gaps when using upmpdcli with mpd. The last factor (gapless) may depend on the control point used, but playing should certainly be gapless with "good" control points (e.g. Bubble, Kazoo, upplay).

Just a few words to explain what happens when you use upmpdcli, my apologies to the people who know all of it already.

There are 4 elements in play:


  1. The UPnP Media Server holds data and metadata (titles etc.)
  2. The UPnP Control Point is your interface to the system
  3. upmpdcli is the UPnP front-end to MPD. It receives UPnP command on the front, and behaves as a normal MPD client on the back.
  4. MPD plays the music :)

When choosing and playing tracks, the process is as follows:


  • The Control Point reads metadata and URLs (http://...) from the Media Server and displays the metadata.
  • You chose titles to play, and the Control Point sends the metadata and URL to upmpdcli.
  • upmpdcli adds the URL to the MPD playlist exactly as "mpc add" would.
  • MPD uses its "curl" input plugin to fetch the audio data from the Media Server.

The two important points are:

  1. Only MPD and the Media Server touch the audio data. The Control Point and upmpdcli only deal with URLs and metadata.
  2. Seen from MPD, upmpdcli is just another client, using the standard client protocol to add tracks designated by HTTP URLs.
This means that when there are track transition issues (pops, gaps...), you should be able to reproduce them without upmpdcli, by adding the URLs directly to MPD with a standard client (e.g. mpc). To find the URL values, you can either browse the Media Server with a diagnostic tool like upnp-inspector, or get them out of /var/log/mpd/mpd.log after playing them with the Control Point.

If you can reproduce the problem with mpc/mpd only, it becomes simpler.

From my experience, there have been a number of bad interactions inside MPD between the "curl" HTTP input method and some decoders. Apart from pure network issues, this is what makes the situation different from playing "normal" files (obviously if the latter are local, but even if they are situated on an NFS or SMB server). These problems could depend both on the data format and data rate (e.g. 44100/16 WAVs would work but not 192/24). I have seen gaps issues being solved by increasing the MPD audio buffer size (but not cracks / pops).

An obvious prerequisite is that the network transfer must support the adequate data rate (client, network, Media Server). For high data rates, a wired link is highly preferrable.

I believed that these problems were all solved by very recent versions of mpd 0.19, if possible configured with --disable-audiofile (libaudiofile does not do anything that libsndfile does not do, and often causes problems in my experience).

From what you are seeing on the BBB, it would appear that this is not the case, I hope that this bit of clarification will help in solving the problem, and I'd be glad to help as far as I can (I can't reproduce the hardware config).

Cheers,

jf
 
Member
Joined 2010
Paid Member
Hi,

As I (Jean-Francois) am subscribed to the diyaudio forums, I think that I could add a few words of explanations.

First, to confirm: it is not normal at all to have noises or cracks or gaps when using upmpdcli with mpd. The last factor (gapless) may depend on the control point used, but playing should certainly be gapless with "good" control points (e.g. Bubble, Kazoo, upplay).

Just a few words to explain what happens when you use upmpdcli, my apologies to the people who know all of it already.

There are 4 elements in play:


  1. The UPnP Media Server holds data and metadata (titles etc.)
  2. The UPnP Control Point is your interface to the system
  3. upmpdcli is the UPnP front-end to MPD. It receives UPnP command on the front, and behaves as a normal MPD client on the back.
  4. MPD plays the music :)

When choosing and playing tracks, the process is as follows:


  • The Control Point reads metadata and URLs (http://...) from the Media Server and displays the metadata.
  • You chose titles to play, and the Control Point sends the metadata and URL to upmpdcli.
  • upmpdcli adds the URL to the MPD playlist exactly as "mpc add" would.
  • MPD uses its "curl" input plugin to fetch the audio data from the Media Server.

The two important points are:

  1. Only MPD and the Media Server touch the audio data. The Control Point and upmpdcli only deal with URLs and metadata.
  2. Seen from MPD, upmpdcli is just another client, using the standard client protocol to add tracks designated by HTTP URLs.
This means that when there are track transition issues (pops, gaps...), you should be able to reproduce them without upmpdcli, by adding the URLs directly to MPD with a standard client (e.g. mpc). To find the URL values, you can either browse the Media Server with a diagnostic tool like upnp-inspector, or get them out of /var/log/mpd/mpd.log after playing them with the Control Point.

If you can reproduce the problem with mpc/mpd only, it becomes simpler.

From my experience, there have been a number of bad interactions inside MPD between the "curl" HTTP input method and some decoders. Apart from pure network issues, this is what makes the situation different from playing "normal" files (obviously if the latter are local, but even if they are situated on an NFS or SMB server). These problems could depend both on the data format and data rate (e.g. 44100/16 WAVs would work but not 192/24). I have seen gaps issues being solved by increasing the MPD audio buffer size (but not cracks / pops).

An obvious prerequisite is that the network transfer must support the adequate data rate (client, network, Media Server). For high data rates, a wired link is highly preferrable.

I believed that these problems were all solved by very recent versions of mpd 0.19, if possible configured with --disable-audiofile (libaudiofile does not do anything that libsndfile does not do, and often causes problems in my experience).

From what you are seeing on the BBB, it would appear that this is not the case, I hope that this bit of clarification will help in solving the problem, and I'd be glad to help as far as I can (I can't reproduce the hardware config).

Cheers,

jf

Hi Jean-Francois,

I really appreciate that you kindly join us in the thread helping me in this issue and giving to us the detailed explanation. Thanks!

This morning I make the following steps in putty to understand if I can reproduce the problem with mpc/mpd only without upmpdcli active:

1 - I run grep http /var/log/mpd/mpd.log

2 - From the list I copy just one line (Feb 20 00:21 : player: played "http://192.168.0.6:50002/m/NDLNA/7355.flac")

3 - I stop the upmpdcli with sudo /etc/init.d/upmpdcli stop - Putty reply : [OK] Stopping upmpdcli (via systemctl): upmpdcli.service.

4 - I cleaned the playlist with with mpc clear

5 - I added some traces from the list I get with mcp add http://192.168.0.6:50002/m/NDLNA/7355.flac (I added some other traces just changing the number after the NDLNA)

6 - With mpc play and mcp next I can run the 8 traces that I created in the playlist

The result is the same and in two traces even worse... the time of glitches, pops and trace jumps getting longer, 10 to 12 seconds.
After the first second the trace is perfectly played up to the next trace.

My network is a typical home wireless network where the NAS (media server) and the BBB are wired link to the router.

Sorry, I didn't mentioned before. In the same network I use for long time the RPI with Volumio and I never face this kind of issues...

Thanks again for your time and Best Regards,
Enrico
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.