Posts by Heinrich

    Das kann sein,

    auf meinem Zero hätte ich mir dieses Update auch lieber sparen sollen.

    Da läuft die Minimalinstallation ohne X und nach dem Update

    scheint die Audioausgabe über die GPIO Pins nicht mehr zum Laufen zu bringen

    zu sein. -echter Knieschuß!

    Vorher lief es einwandfrei.

    Installiert habe ich Buster und vor zwei Tagen dieses neue 2020 Update

    durchgeführt. Das läuft auf meinem Raspi 4B

    Ansonsten ist das so, wie ich es hier schon ausgebreitet habe.

    Darf mich mal selbst zitieren:

    Quote from mir

    Man darf den Einstellungsdialog des Pagers nicht aufrufen,

    tut man das, schaltet der ganze Desktop plötzlich auf "Openbox".

    In der Titelleiste des Einstellungsmenüs steht dann auch:

    "Openbox Einstellungsmanager"

    -aber da ist es dann schon zu spät :)

    Aber ich kannte das Spielchen schon, das ist mir vor ein paar Jahren schonmal mit Pixel passiert.

    Ich kann das auch reproduzieren, is halt so.

    Nee, das hat zuviele Seiteneffekte, bzw. funktioniert das nicht konsistent.

    Versuch doch mal in den Einstellungen des Pagers von 4 auf 2 Desktops

    runterzustellen, wie ichs beschrieben habe.

    Des Rätsels Lösung:

    Man darf den Einstellungsdialog des Pagers nicht aufrufen,

    tut man das, schaltet der ganze Desktop plötzlich auf "Openbox".

    In der Titelleiste des Einstellungsmenüs steht dann auch:

    "Openbox Einstellungsmanager"

    -aber da ist es dann schon zu spät :)

    Ich hatte die Anzahl der Desktops auf zwei runtergestellt,

    weil ich keine vier brauche.


    Aber selbst, wenn ich den Einstellungsmanager nicht anfasse,

    kann ich mit [Strg]+[F2] offenbar den Desktop nicht wechseln,

    was blöd ist, da ich auf einem Desktop sunvox im Vollbild laufen lassen wollte

    und auf dem Anderen den Mixer bzw. das Manual oder Qjackctl laufen lasse.

    Ist aber kein Drama, geht ja auch alles auf einem Desktop

    und dann bemüht man halt [Alt]+[Tab].

    Das ist mir halt nur etwas unübersichtlicher.


    Könnt Ihr ja selbst mal testen:

    Rechte Maustaste auf das Pagericon in der Titelleiste => Desktop-Pager Settings

    Das läd die Openbox Settings

    Zurück gehts mit linker Maustaste irgendwo im Desktop => Desktop Einstellungen => Defaults

    Erstmal Dank


    Quote

    Pixel? Ist Dein OS so alt?

    Heißt das nicht mehr so?

    -hab ich wohl was verpaßt.


    Funktioniert jedenfalls,

    aber irgendwie hauts jetzt auf einmal mit der Maus

    garnicht mehr hin:

    Mit der linken Taste kann ich den Fokus nicht mehr

    auf ein anderes Fenster setzen,

    das geht nurnoch mit [Alt]+[Tab] auf der Tastatur.

    Fenstergröße läßt sich auch nicht mehr

    mit [Alt]+[linke Maustaste] skalieren

    oder mit [Alt]+[rechte Maustaste] verschieben.

    Die geöffneten Fenster lassen sich in der Titelleiste

    mit Maus garnicht mehr bedienen, sprich: Zumachen, Maximieren oder Minimieren


    wasndas?




    Näää, das hat zuviel Seiteneffekte.

    Hab den Pager wieder rausgenommen und den "Default for large screens" wieder hergestellt.

    Der Pager scheint die Openboxeinstellungen zu bevorzugen,

    das haut aber die ganze Bedienbarkeit über'n Haufen.


    Habt trotzdem Dank,

    bin ich halt schlauer.

    :)

    Hab Dank,

    Quote from https://www.raspberrypi.org/blog/new-raspberry-pi-os-release-december-2020/

    This is a know issue and is being worked on at the moment

    – hopefully we’ll have a fix soon.

    That's what I hope too !


    Der Zero ist für mich jedenfalls nicht brauchbar, wenn er keinen Ton von sich geben kann

    und mit einer kompletten grafischen Oberfläche werde ich das Winzding nicht kastrieren.

    Sicher wissen da viele Fachkundigere im Augenblick auch noch nicht mehr,

    das kam doch etwas abrubt.


    Was Raspbian betrifft denke ich mir: Abwarten und Tee trinken

    Ansonsten mal wieder gucken, was Arch so macht.

    Da gibts ja für Arm6 sogar einen separaten Kernel.


    Bin natürlich trotzdem Dankbar für weitere Hinweise.

    Ich habe "pulseaudio" auf Dunst schon nachinstalliert,

    das hat mir mehrere hundert Megbyte auf das Kärtchen gemüllt,

    aber getan hat sich nix.


    Ob denn Audio ohne Xserver jetzt überhaupt noch funktioniert???

    Tschööö,

    die Audioausgabe in der Shell scheint nach dem letzten Update

    nicht mehr zu funktionieren.

    Installiert ist auf meinem Raspi Zero W das Minimalimage

    und mpg123 (natürlich u.A.).

    X ist nicht installiert und der Zero läuft headless.

    An dem Zero ist ein selbstgelöteter Hoch- Tiefpaß

    an den entsprechenden GPIOs angebracht

    und bis jetzt hat das brav und klaglos mit den folgenden

    Einträgen in der /boot/config.txt funktioniert:



    # Enable audio (loads snd_bcm2835)

    # pwm Ausgänge fuer Zero umbiegen:

    dtoverlay=pwm-2chan, pin=18, func=2, pin2=13, func2=4

    dtparam=audio=on


    nach dem Update: Tutenblasen!


    unter /dev/snd/ taucht nurnoch folgendes auf:


    -seq

    -timer


    Ich hab das o.G. in der config.txt dann nochmal auskommentiert,

    den Zero neu gestartet und ein USB Codec drangehängt.

    Der erscheint nun zwar unter /dev/snd,

    mpg123 beschwert sich allerdings, daß es keinen "jack server" findet

    und quittiert sein Beenden noch mit "Speicherzugriffsfehler".

    mpg123 hat sich bis jetzt immer völlig mit dem puren Alsa begnügt.

    aplay spuckt ebenfalls nurnoch Fehlermeldungen aus,

    wenn ich versuche damit eine Sounddatei abzuspielen:


    Code
    aplay crystal_lake.wav
    ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
    ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_card_driver returned error: Datei oder Verzeichnis nicht gefunden
    ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
    ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_concat returned error: Datei oder Verzeichnis nicht gefunden
    ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
    ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_refer returned error: Datei oder Verzeichnis nicht gefunden
    ALSA lib conf.c:5047:(snd_config_expand) Evaluate error: Datei oder Verzeichnis nicht gefunden
    ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
    aplay: main:828: Fehler beim Öffnen des Gerätes: Datei oder Verzeichnis nicht gefunden


    lsmod sagt Folgendes:

    -keinen Plan, was da schief läuft.

    Kann es sein, daß dieser ganze v4l Krempel da querschießt?

    Darf ich hoffen, daß das nach dem "großen Update 2020" irgendwann gefixt wird?

    Fragen über Fragen...


    Nachtrag:

    Folgende Fehlermeldung finde ich noch in "dmesg":

    "

    Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,model-zero-w.txt failed with error -2


    "

    WLAN pfundst aber, bin ja mit ssh im Zero.



    Wäre sehr dankbar für sachdienliche Hinweise.

    Hi,

    im Prinzip ist es mit Overlay ja sogar einfacher,

    aber was nervt ist, daß, wenn man überhaupt erst

    darauf gekommen ist, daß mit der Software was nicht mehr stimmt

    und weiß, daß die Hardware immer noch in Ordnung ist,

    im "Google Archiv" eine aktuelle Lösung zu finden.

    Meistens gibts da ja bei älteren SPI/I²C oder

    GPIO Gadgets auch schon mehrere Treibergenerationen.

    Tja, und wenn man Pech hat, muß man selbst am Kernel basteln

    oder erklärt sein Gadget gleich zu Elektronikschrott.

    Sehr "nachhaltig" ist das nicht.

    -naja, ein altes Lamento :)

    Gute 11 Monate später:


    Tjaaa,

    das wars mal wieder:

    apt-get upgrade, neuer Kernel und das Display bleibt weiß nach reboot.


    Des Rätsels Lösung:

    Es gibt kein "fbtft_device" Modul mehr.


    ...

    Gibt jetzt aber ein overlay namens "adafruit18"

    Hab Folgendes in meiner /boot/config.txt nachgetragen:


    dtparam=spi=on

    dtoverlay=adafruit18


    ...und die Sache läuft wieder auf dem oben von mir genannten "SainSmart ST7735"


    greets

    Quote

    Soundqualität einer HiFiBerry DAC+ Pro im Vergleich zur Soundblaster Live Value

    Hi,

    die Soundblaster Live war ja nun auch als Musikinstrument zu nutzen.

    Ich weiß nicht, ob du vor hast, mit dem Raspi evtl. Musik zu machen.

    Falls dem so ist und Du möchtest auch mal z.B. mit Sunvox, Lmms, Zynaddsubfx, Fluidsynth usw.

    produktiv werden, scheinen mir die HIFIBerrys dafür nicht sonderlich geeignet.

    Die mögen zwar sehr gut klingen, haben aber wohl grauenhafte Latenzen

    und sind in dieser Hinsicht mitnichten einer PCI Soundkarte gleichwertig.

    Hier:

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    gibt es einen schönen Vergleich der Latenzen von HIFIBerry DAC+ und dem Behringer

    UCA202 USB Audio, wobei letzteres natürlich auch über einen guten Stereo-ADC

    mit Line Eingang verfügt (Der CODEC da drin ist nach meinen Recherchen sogar ein Burr/Brown von TI:

    PCM2902.)


    Für jemanden, der nur Audio über den Raspi hören möchte, ist die Frage der Latenz

    wahrscheinlich nicht so interessant, aber was mich noch interessieren würde ist,

    ob sich diese Latenz auch bei Filmwiedergaben (Youtube, mplayer usw.) bei dem HIFIBerry bemerkbar macht

    (Lippensynchronizität)?

    Hast Recht,


    Beim boot von der SD-Karte zeigt er das an:

    /dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)

    /dev/mmcblk0p2 532480 60405759 59873280 28,6G 83 Linux

    /dev/mmcblk0p3 60405760 249737215 189331456 90,3G 5 Extended

    /dev/mmcblk0p5 60407808 249737215 189329408 90,3G 83 Linux


    Beim boot von SSD wird das daraus:

    /dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)

    /dev/sda2 532480 60405759 59873280 28,6G 83 Linux

    /dev/sda3 60405760 468862127 408456368 194,8G 5 Extended

    /dev/sda5 60407808 468862127 408454320 194,8G 83 Linux


    Hab da wohl was durcheinandergebracht.


    Noch was anderes:

    Was mir auch noch auffällt ist,

    daß die Aktivitätsled des Raspi viel höhere Aktivität

    zeigt, wenn ich von SSD boote.

    Selbst wenn ich kein Programm laufen lasse, flackert die

    fast regelmäßig etwa im Sekundentakt.

    Mitunter ist sie durchgehend mehrere Sekunden an.

    Wenn ich von SD Karte starte passiert das nicht.

    Keine Ahnung, was das macht,

    aber das nervt!

    Na, das war simpel:


    Habe gerade das System von der internen SD-Karte(SanDisc Ultra Micro SDXC I, 128GB)

    meines Raspi4(2GB) mittels "piclone" auf eine am USB3 über einen USB-SATA Konverter

    angeschlossene "SanDisc Extreme 240GB" SSD gespielt.

    Man findet "piclone" im Programmenü unter "Zubehör"=> "SD Card Copier".


    "lsusb -v" sagt zum USB3-SSD Adapter:

    Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name:

    ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge,

    ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge


    "piclone" gab zwar bei Aufruf Fehlermeldungen,

    hat aber brav kopiert.


    Nochmal der Reihe nach:


    System normal mit SD-Karte hochfahren, als pi anmelden.

    Festplatte über Adapter am USB3, einem der Blauen, anschließen.

    (Weiß nicht, ob das nötig war, aber ich habe dann erstmal alle

    Partitionen auf der SSD gelöscht.)

    Programm über Programmenü => "Zubehör"=> "SD Card Copier" starten.

    Einstellen: "Von Gerät kopieren" => SD Karte

    "Auf Gerät kopieren" => SSD HD

    Anklicken: "New Partition UUIDs"

    => "Start" und etliche Minuten warten, bis Meldung "Partitionen kopiert" oä kommt.

    Rechner runterfahren (hab zur Sicherheit als root vorher noch ein "sync" abgesetzt)

    und Stecker raus.

    SD-Karte rausnehmen und nur noch mit SSD neustarten.


    Der Neustart lief bei mir glatt, aber was mir noch auffiel ist,

    daß das Programm sogar meine letzte und grösste Datenpartition in der Größe

    auf den maximal übrigen Platz auf der SSD angepaßt hatte.


    Desweiteren zeigt mir als root "fdisk -l" für die Partitionen

    keine "UUIDs" mehr, sondern bindet die als "/dev/sda1, ...sda2, ...sda3 und ...sda5" ein.



    Noch zu erwähnen, daß ich vorher alles was möglich war geupdatet hatte:

    Pi 4b Kernel: 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux


    "rpi-eeprom-update":

    Dedicated VL805 EEPROM detected

    BOOTLOADER: up-to-date

    CURRENT: Fr 31. Jul 13:43:39 UTC 2020 (1596203019)

    LATEST: Fr 31. Jul 13:43:39 UTC 2020 (1596203019)

    FW DIR: /lib/firmware/raspberrypi/bootloader/stable

    VL805: up-to-date

    CURRENT: 000138a1

    LATEST: 000138a1


    So,

    meine einzige Frage bleibt noch,

    ob das irgendwelche Auswirkungen auf das System oder Programme hat,

    wenn die Partitionen jetzt nicht mehr mit "UUIDs" angesprochen werden?

    Thx

    Wenn Du mit der rechten Maustaste irgendwo auf dem Desktop ins Leere klickst,

    bekommst Du ein Pulldownmenü:

    Ganz unten auf "Desktop Einstellungen" klicken.

    Da erscheint das Menü "Appearence Settings".

    Da klickst Du oben auf den letzten Reiter "Defaults".

    Darunter erscheinen drei Wahlmöglichkeiten:

    "For large screens" mit dem Knopf "Set Defaults",

    "For medium screens" - "Set Defaults"

    und "For small screens" - "Set Defaults"

    -einfach ausprobieren.

    Das wäre aber merkwürdig. Kannst du aber selber einfach herausfinden. Wenn beim nächsten Upgrade neue Firmware installiert werden soll, dann einfach mit (n)ein abbrechen und dann mit apt-get dist-upgrade gucken, ob die Firmware auch installiert werden will.

    Ich habe nochmal nachgeguckt und ich glaube, Du hast -bis auf das letzte Kernelupdate (auf 5.4.51-v7l+)- Recht.

    Die Bootloaderversion war vor dem, danach per "rpi-eeprom-update" installierten:

    "Do 16. Apr 17:11:26 UTC 2020 (1587057086)"


    Die VL805-Firmware:

    "FW DIR: /lib/firmware/raspberrypi/bootloader/critical

    VL805: up-to-date

    CURRENT: 000137ad"


    Das stammte allerdings nicht, wie ich oben geschrieben habe, noch von 2017.

    Asche auf mein Haupt!


    Mit dem Kernelupdate von 4 auf 5 vorgestern mit "apt-get dist-upgrade"

    wurde allerdings ein neuer Bootloader, sowie eine neue VL805-Firmware geliefert,

    die nicht per dist-upgrade installiert wurden.

    Ein bloßes absetzen von "rpi-eeprom-update" zeigte nach Kernelupdate und "reboot"

    immer noch die o.g., alten Versionen.


    Die mußte ich, 1. mit:

    rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-07-16.bin

    -kleines Stoßgebet und "reboot"

    Dann 2. , nach Neustart mit:

    rpi-eeprom-update -a

    -noch'n Neustart,

    installieren.


    Soweit ist das alles glücklich verlaufen:

    Kernelnr. ist jetzt 5.4.51-v7l+, Bootloader: Do 16. Jul 15:15:46 UTC 2020 (1594912546)

    und VL805-Firmware: 000138a1


    Werde bei den nächsten "dist-upgrades" mal besser drauf achten.

    Übrigens:

    Das:

    Quote

    Note that if a bootcode.bin is present in the boot partition of the SD card in a Pi 4, it is ignored.

    stimmt nicht!

    Ich habe hier nach Flashen auf die aktuelle Firmware immer noch unter "/boot" eine "bootcode.bin".

    Der Raspi bootet allerdings immer noch brav von seiner SD-Karte.


    -Naja, vlt. guckt er sich dabei die "bootcode.bin" nicht mehr an.

    :)