marc

Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • 1. Oktober 2019 at 11:57 #47213

    Hi Heiner,

    the specific reason why one of the A+ Pi’s worked with the 2.26 wheezy instead of the 2.44 jessie is just the sound card and the 2.26 device has a more powerful power supply since it is using an amp. The rest is identical.

    best

    Marc

    1. Oktober 2019 at 6:37 #47207

    Hi Heiner and all,

    I have now tried the legacy images with my different pis and DACs, working my way down from the newest to the oldest images. Turns out that I had to use all 3 images to get the 5 different setups working (for now). The working setups looks like this (please not that it is a bit different from the one I listed initially where I made one mistake):

    1. Raspberry 1 A+, IQaudIO Pi-AMP+, EDIMAX 7811UN WLAN -> m2p_default_226_wps.img
    2. Raspberry 1 A+, HifiBerry DAC+ Pro (B+ / PI 2/3), EDIMAX 7811UN WLAN -> m2p_rpi_default_244_wps_ap_expand.img
    3. Raspberry 1 A+, HifiBerry Digi+, EDIMAX 7811UN WLAN -> m2p_rpi_default_244_wps_ap_expand.img
    4. Raspberry Zero W, HifiBerry DAC+ Zero 1.0.1 -> m2p_stretch_rpi_v249.img
    5. Raspberry Zero W, HifiBerry DAC+ Zero 1.0.1 -> m2p_stretch_rpi_v249.img

    Notably, I could then upgrade the max2play version online on all installations to the newest release, 2.50. An initial test with the following setup did not conclude, here I had to switch to the Raspberry Zero W:

    6. Raspberry Zero, HifiBerry DAC+ Zero 1.0.1, EDIMAX 7811UN WLAN

    As for now, all systems are working for 3 days and reliably stay in the network. I am noting this since my initial venture started because some of the devices were disappearing from the network after undetermined time intervals and without any good handle how to debug. Hence I though a fresh install would solve this problem. However, it just showed the incompatibility with the images as identified now.

    I hope this is helpful for anyone with similar problems. However, it is not an ideal state since I now forced to run three different versions of raspbian with two outdated images. This is increasing administration load and it is canceling out any newer patches, e.g., needed for security reasons.

    • This reply was modified 4 years, 6 months ago by marc.
    4. Mai 2019 at 16:29 #45260

    Hi Heiner,

    There is some more progress in debugging my music system problems. For breaking down the overall problem this is what I did first, also following your advise:

    1. Replaced the apparently faulty SDcard with one of the pi Zero clients (other thread in this forum), this one is now up and running again.
    2. Updated all clients to stretch, indeed, 3 clients were still on the old distribution.
    3. Removed all unnecessary plugins, the clients just run squeezelight.
    4. Enabled SDcard write protect plugin to avoid any damage during tests.
    5. Disabled the lms completely to first see how the clients behave just in the network without any lms server.
    6. Disabled the WLAN mesh and only had one of the two Fritz!Boxes serve the WLAN, this Fritz!Box box is connected via gigabit LAN to the Fritz!Box cable router and DHCP server. Worked like this for years.

    Result:

    – The two pi Zero W clients as well as the original squeeze controller are visible in the network and the m2p web interface of the pi Zero W clients is accessible.
    – The three pi A+ clients (with EDimax WLAN adapter, all purchased from M2P shop) appear after inserting the freshly prepared SDcard with latest m2p image but
    – the access point setup does not work, the password for the network is reported as invalid on connect.
    – The WPS setup takes a long time but after some 10 minutes all clients appear and can be set up similar to the pi Zero W clients (remove unnecessary plugins, enable write protect).
    – Then the A+ clients are visible on the network for some minutes but then suddenly disappear. The router (A Fritz!Box 6590 cable) does not report them anymore in the mesh interface and they can not be accessed either by the web interface or ssh or ping. They seem of the network. A reboot of the A+ clients triggers same behavior, they can be seen for a few minutes in the Fritz!Box network overview (although without any information on the quality of the connection as is normal for any other connected clients), but then disappear again and are inaccessible.

    So I don’t know if this is the reason but it seems highly unrealistic that exactly all the A+ clients create a problem, right? I think this has to be fixed first before I can go on and test the lms on one of the clients as you, Heiner, proposed. Any ideas on this behavior of the systems?

    • This reply was modified 4 years, 11 months ago by marc. Reason: Forgot one step
    3. Mai 2019 at 10:08 #45230

    Dear Heiner,

    ok, I see. Am I right that
    1) updating the m2p version from the clients (currently 2.48) does not update the linux version installed?
    2) reinstalling m2p from the latest 2.48 image does include a new linux (now stretch)?

    About running the server on the pi, it will be possible although not exactly with the same setup since the music data then has to be shared via nfs from the syno. I’ll try this after the potential client update.

    best

    2. Mai 2019 at 16:59 #45219

    Dear Heiner,

    The Logitech Media Server Version: 7.9.2 – 0018.1548605546 is running on a Synology 1513+ NAS, which – as far as i know, uses a tailored linux not really related to any prominent linux distribution. The Synology delivered OS version (called DSM) is up-to-date to the latest available version „DSM 6.2.1-23824 Update 6“.

    Synology also provides an own version of the LMS, but it always is pretty outdated, i.e. it, still is based on 7.7.6-116 which has problems with several newer plugins. Hence I did install the newest version from the user pinkdot found here:

    https://forums.slimdevices.com/showthread.php?108960-Synology-7-9-2-packages

    Point is, this did run ok until I upgraded m2p to 2.47 and then 2.48

    best

    30. April 2019 at 16:21 #45192

    Dear Heiner,

    No, unfortunately it seems different. The other post can be closed after I replaced the faulty SDcard and this one client is now up and running again. I wanted to solve the latter first to make sure it wasn’t a cascading error, i.e., the one faulty client somehow messes up the connection of the other ones.

    This problem here is still there and the debugging is really hard.

    best

    27. April 2019 at 17:03 #45160

    Dear Heiner,

    I tried a new SDcard and it works again. I know its not a big deal but the faulty SDcard has been purchased with a pre-installed m2p from your shop last year, 22.5.2018. It is a Samsung 8GB. I couldn’t find any information about warranty but I guess since it is not even one year it should be covered. Any chance of a replacement?

    best

    Marc

    16. Februar 2017 at 20:23 #26997

    Hallo Heiner,

    danke für die Rückmeldung. Wie ich aber schrieb, kam bei dem Versuch mit HiFiBerry DAC gar kein Sound. Ist es sicher dieses Device?

    Marc

    4. Februar 2017 at 14:18 #26670

    Hallo,

    ich bin auch dabei, neben bereits 4 laufenden A+ mit verschiedenen HIFIBerry und IQ’s jetzt einen Pi Zero mit der Hifiberry Dac+ zero Platine ans laufen zu bringen. Du schreibst:

    „Unter Menüpunkt HIFIBerry ist die Karte angegeben und gespeichert.“

    Bei mir erscheint leider die „Hifiberry Dac+ zero“ gar nicht unter den verfügbaren devices, obwohl ich das aktuelle Image geladen habe. Wie bekommt man denn die Auswahl, auch die „Hifiberry Dac+ zero“ zu wählen?

    danke

    25. Januar 2017 at 9:57 #26289

    Ich noch einmal,

    wie wäre es denn, bei der Auswahl der Pi’s (mit oder ohne Soundkarte) auch den A+ anzubieten? Sowohl als Einzelgerät als auch in den Bundles. Da er Zero noch baw eher schlecht zu bekommen ist, ist der A+ die einzige Lösung, wenn man wirklich auf minimalen Energieverbrauch setzt oder setzen will (etwa, wenn man eben mehr als ein Gerät plant). Ist halt schon eine Unterschied, ob ich <1W bleibe (auch unter Last) oder bei 2W (Ruhe) – 4W (Last) wie etwa beim Pi3.

    25. Januar 2017 at 9:21 #26288

    Hallo alle,

    das ist interessant hier. Ähnliche Überlegungen habe ich auch angestellt beim Aufbau einer größeren Multiroom Installation. Die Aussage, theoretisch müsste der HDMI-Ausgang genau so klingen wie der SPDIF auf dem Audio Bord (zumindest solange man in der unterstützen Maximalfrequenz bleibt) fußt ja meistens auf der Annahme: Digital = Digital, daher kein Unterschied.

    Ich spekuliere hier einmal nach reichlich Lesen diverser Lektüre zu diesem Thema. Please correct me if I am wrong 😉 Digital = Digital ist im Prinzip ja auch völlig korrekt. Im technischen Detail sieht es aber doch schon etwas anders aus. Die Signal-erzeugende Instanz (also der Pi oder das Audio Bord) müssen ja auch die notwendigen Signal- und Übertragungfrequenzen erzeugen können. Dieses kann im Prinzip nur aus den jeweils verfügbaren Quellen (den Oszillatoren auf den Bords) erzeugt werden und als clock Signale anderen Anwendungen zur Verfügung gestellt. Auf dem Pi haben wir etwa die folgenden Quellen (S. 102-108):

    https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

    Ein beliebiger Clock-Takt lässt sich ideal nur durch ganzzahlige Teilung einer schnelleren Clock erzeugen oder ich bekomme Jitter. Der Pi unterstützt dabei auch schon weitreichende Funktionen gegen dieses Problem, s. MASH. Ob und wie diese bei der Ausgabe eingesetzt werden ist (oder sollte) softwareseitig definiert (werden) afaik. Dazu müsste man schon in den Quellcode schauen (dazu hatte ich aber noch keine Zeit). Ein deutliches Indiz für eine Jitter Problematik ist, dass die HIFIBerry DACs eigene Oszillatoren haben (der pro sogar deren 2). Und die sind genau gegen dieses Problem:

    DAC+

    Um es nicht zu lang zu machen: zumindest könnte dies (Aufbereitung des Digitalsignals, möglicher Jitter) eine Quelle eines „gespürten“ oder wirklich „gehörten“ Unterschieds zwischen HDMI auf dem Pi und SPDIF auf dem Audio Bord sein. Wie dann die weitere Ausgabekette auf die nun unterschiedlich erzeugten digitalen Signale reagiert kann auch nur spekuliert werden. Vielleicht kann man es hören, vielleicht bildet man es sich ein. Allerdings kann man sich schon herleiten, dass es zumindest Unterschiede zwischen den Ausgaben über die verschiedenen Verbindungen geben könnte und nicht einfach „Digital=Digital“ gilt.

Viewing 11 posts - 1 through 11 (of 11 total)