Posts by Heinrich

Tja, das ist nun schon ein Weilchen her,

aber ich stolpere nun wieder über den Faden und wollte das noch ergänzen:

Es gab mehrere Programme, die sich plötzlich, nach Updates ähnlich zäh

verhielten und auf einmal unglaublich viel CPU Zeit fraßen;

Dazu gehörte, neben dem erwähnten "hatari", auch das von mir sehr geschätzte "sunvox".

Ich bin nun auf etwas eigentlich Naheliegendes nicht gekommen: Der Grafiktreiber.

Die erwähnten, neuen Versionen der Programme laufen nurnoch mit dem "experimentellen GL Treiber"

vernünftig und flutschen, ist der über die /boot/config.txt mit dem Eintrag:

dtoverlay=vc4-kms-v3d geladen, sogar besser als die vorherigen Programmversionen

mit dem Standardtreiber, der sonst per default geladen wird.

Der mplayer und vlc lassen sich dann überhaupt erst sinnvoll nutzen,

genau wie der Atarisimulator "hatari" in der Version >= 2 und neuerdings auch "sunvox".

Das wirklich Ärgerliche ist aber, das dann das Youtubefilmgucken mit dem GL-Treiber und dem chrome-browser

überhaupt keinen Spaß mehr macht. Der ruckelt dann schon fürchterlich nur beim Seitenscrollen

und Filme gucken kann man so absolut vergessen.

Irgendwelche Updates muß ich also ergo garnichtmehr verhindern, weil die Programme

neuerdings mit den richtigen Treibern wunderbar laufen.

Hey,

ich danke Euch.

Ich bin DBVs Tip nachgegangen.

Synaptic habe ich natürlich installiert:

Dort das Paket suchen und selektieren,

dann unter Pulldownmenü "Paket"

"Version sperren" anklicken und

das Upgrade läßt das Paket in Ruhe.

Thx!

Hi,

ich wollte gerade ein apt-get upgrade laufen lassen und

habe glücklicher Weise nochmal durchgeguckt, was "geupgraded"

werden soll.

Ich habe hier den Atari-ST Emulator "hatari" auf einem Raspi 3 mit dem

aktuellen "Stretch", Kernel 4.9, am laufen und brauche den

für einen speziellen MIDI-Synthesizereditor.

Die einzig einigermaßen brauchbare Version, hatari 1.9 hatte ich als Binärpaket

für Raspbian irgendwo im Netz gefunden und per dpkg installiert.

Die unter Jessie mitgebrachte Version hatari 1.8 wollte auch nicht richtig.

Version 2, die in den aktuellen Raspbian Repositories für Stretch angeboten wird,

verursacht eine unglaubliche Prozessorlast, braucht etliche Minuten

fürs Starten und läuft entsprechend so zäh, daß man damit kaum arbeiten kann.

Da ich hatari immer aus der Konsole aufrufe,

sehe ich auch bei der Version 1.9 ständige Fehlermeldungen

im Hintergrund, in der Konsole:

Das wiederholt sich ständig mit unterschiedlichen Adressen,

scheint den Programmablauf aber nicht sonderlich zu stören

und die Prozessorlast steigt beim Ausführen von YSEDIT.PRG unter hatari 1.9

kaum über 20%.

-soweit so mäßig,

nun will aber apt-get upgrade mein schönes hatari 1.9 wahrscheinlich wieder

auf die träge Version 2 upgraden.

Wie kann ich das verhindern und trotzdem alles andere upgraden?

Quote

Könntest du das bitte etwas näher erläutern?
Sprichst du von tatsächlichem Qualitätsverlust?
Das ist nämlich wirklich auch was, was mir hier im Kopf rumgeistert.
Ist zwar schön, ein anständiges und komplexes Routing zu haben,
aber ich fürchte halt auch, dass das Signal da deutlich drunter leiden könnte.

Display More

Der Vorteil dieser 40xx CMOS Analogschalter liegt darin, daß sie schon ab
einseitigen +3V UB arbeiten.
Mit der Onboardspannung des Raspi von 3,3V sollte man fürs Schalten also schon gut auskommen.
Bei den etwas teureren von Maxim: DG401, DG403, DG405 z.B. -wenn man die überhaupt noch bekommt-
wird lt. Datenblatt eine höhere Betriebsspannung von +/- 15V vorausgesetzt.
Letztere bedeuten also einen beträchtlich höheren Schaltungsaufwand,
da man dafür schon extra Spannungsquellen bräuchte und die Schaltspannung vom Raspi
wahrscheinlich auch wenigstens auf TTL-Pegel verstärkt werden müßte.
Bei den 40xx ist auch darauf zu achten, daß die Spitzen- oder Scheitelspannungen
des Eingangssignales die Betriebsspannung auf keinen Fall überschreiten.
Da hat man bei 3,3V Peak to Peak -das sind etwa 1,17V effektiv- nicht sehr viel Luft,
d.h. das Audiosignal darf keine große Dynamik haben, sonst zerrts.
Eine einfache Schaltung mit den 40xx würde dann auch recht hochohmig
und hat eben die kleine Betriebsspannung,
was mehr Rauschen, Brummen und induktive Empfindlichkeiten mit sich führen könnte.

Ich habe das selbst noch nicht probiert und das ist nur so meine
Kosten-Nutzenabwägung. Ist also wirklich zu überlegen,
ob man sich nicht doch lieber diese ca. 100 Euronen ans Bein bindet.

Quote

"mechanische" Muxer gibt, die ihren Zustand auch ohne Spannung beibehalten können

Gibts: Diese Relais nennen sich "bistabil".

Ich glaube aber, wenn Du komplexere Schaltereien mit ner Masse von Relais realisierst,
bekäme die Kiste den Charm einer Telefonschaltanlage aus den Sechzigern :)

Quote

Gibt es ICs für sowas?

Die Billigversionen wären C-MOS Analog-Schalter, wie 4066, oder 4051 z.B.
Das braucht allerdings schon Einiges an Entwicklungsarbeit,
damits einigermaßen klingt.

Quote

Täusche ich mich, oder gilt das nur den Anschluss an die Klinkenbuchse des Raspi?

Das gilt, in der Tat, nur für die PWM-Wandlung des Raspi, wirkt allerdings Wunder
am Klinkenausgang.
HiFi-Puristen werden da sicher immer noch was zu meckern haben,
aber ich höre mit diesen Parametervorgaben kaum noch dieses eklige
Quantisierungsrauschen in den leisen Passagen.
Mich wundert es nur, daß die in keiner Distri, die ich kenne, schon per default
so vorgegeben sind.

Auf alle Fälle füge ich immer folgenden
Paramerer hinter

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

in der /boot/config.txt ein:

audio_pwm_mode=2

Probiers mal, das wirkt schon Wunder und dann zerrt
auch nichts mehr in den leisen Passagen.

Cool :)
Man könnte den parallel noch als Internetradio
oder mp3-Player laufen lassen.
Es gibt da winzige "class d", 5V Stereoverstärker,
nur die Boxen müßten halt etwas größer sein.

Hab vielen Dank,
viele Wege führen nach Rom
und ich habs mittlerweile mit "ntpdate" hingekriegt,
allerdings ist es nicht schlecht, wenn der Port nicht benutzt wird.

Hier nochmal meine Lösung komplett.
Erstmal:
systemctl disable ntp
und:
apt-get install ntpdate

Timeserver suchen, ich habe den genommen:
de.pool.ntp.org

Dann kleines Skript geschrieben: " /home/pi/zeit.sh" :

Das "-e" führt das folgende Kommando "ntpdate de.pool.ntp.org" aus.
Das "-hold" läßt das Terminal offen, damit man lesen kann, was sich getan hat.

Rechte auf das Skript setzen:
Besitzer root: rwx, Gruppe pi: rwx, alle andern: r
Oktal: 100774

Skript automatisch starten.
In der Datei:
/home/pi/.config/lxsession/LXDE-pi/autostart
folgendes anfügen:
@/home/pi/zeit.sh

Wenn ich mich jetzt als pi einlogge, erscheint ein kleines Terminal
und das Skript wird sichtbar ausgeführt.

Quote

Ein 8 Ohm Lautsprecher direkt an die GPIOs ??!

Der angegebene Widerstand auf dem Lautsprecher ist eine Impedanz,
die entspricht meist dem realen Widerstand.
-Soviel vorweg.
Der Strom an nem nackten GPIO:
I = 3,3V / 8 Ohm = 0,4125 A oder 412,5mA
Zudem ist ein Lautsprecher eine Spule, die durch Selbstinduktion
Rückspannungen erzeugt.

Viel Glück!

Soo,
>systemctl disable ntp
Hat er gemacht und ich habe dafür ntpdate installiert
als root:
>ntpdate de.pool.ntp.org>/root/timeserver
stellt mir die Zeit 1x und beendet sich dann.
in /root/timeserver steht dann die Ausgabe des Kommandos.
Ich habe versucht, das in der /etc/rc.local unterzubringen,
aber erstens ist da wohl leider das Netz noch nicht oben
und zweitens meckert der systemd.
Wie und wo kriege ich das denn automatisch gestartet?

Desweiteren ist mir aufgefallen, daß dhcpcd oder dhcpd läuft,
obwohl ich eine feste ip vergeben habe.
Das scheint zwar neuerdings nötig zu sein um die feste ip zu vergeben,
aber dann muß doch auch kein Dämon mehr geistern.
Wenn ich Folgendes mache, nachdem die vorgegebene ip (wohl mittels dhcpcd)
auf eth0 etabliert ist:
>service dhcpcd stop
...bleibt sie persistent. Wozu dann also noch der Dämon?

Och Kinder!
Ich will hier keine Glaubenskriege auslösen.
Der Pi läuft bei mir höchstens mal 6 bis 7 Stunden am Stück.
Wenn der nun 1x nach der Zeit fragt und nach 7 Stunden dann um 2 Sekunden falsch läuft,
pupst sich das flach!
Also halte ich es für unnötig, daß der von jeder "datenbitch.de" (s.o.) unbedingt die Zeit wissen will.

Quote

Die "fake-hwclock" speichert nur (... zwischen boot und reboot)

Danke für die Info.

Quote

Wieso stört dich das überhaupt so?

Reine Gewohnheit.
Mein Router steht neben dem Monitor und ist auf 6 Minuten Timeout gestellt.
Als der nichtmehr den Hörer auflegte während ich nicht im Netz war,
habe ich "iptraf" installiert und da konnte ich dann sehen,
das er munter nach der Uhrzeit durch die Gegend schreit:

... usw.
Ich denk mir eben, das muß nicht sein.
Mir ist es sowieso völlig wurscht, ob der Pi weiß wie spät es ist,
aber wenn die Zeitdifferenz zu heftig wird, weigert sich der Browser
leider https-Seiten zu öffnen.

Hab jetzt erstmal den Tip von ThomasL oben probiert:
service ntp stop
Unter "htop" sehe ich jedenfalls nichts mehr mit "ntp"

Hi und Danke erstmal kann ich erst nachher ausprobieren.

Quote

Dann hat dein PI, aber evtl. nicht die richtige Uhrzeit. Ist das Absicht?

Na, der soll sich beim Hochfahren die Zeit holen und dann den Dienst abstellen.
Geht denn die "fake-hw-clock" so schnell falsch?

Hi,
weiß jemand, wie ich es hinkriege,
daß der Raspi (Raspi 3b Raspbian Pixel)
nur einmal beim Hochfahren seine fake-hw-clock
nach ntp, ntpdate oder sonstwas einstellt
und dann nicht mehr im Netz nach der Zeit rumfunkt?

Dank im Voraus für Sachdienliches.

Hi,
ich habe hier einen Bluetooth Lautsprecher "xquisit xqbeat 2.0"
und spreche den über den Raspi 3B an.
Das funktioniert sehr unzuverlässig.
Der längste, kontinuierliche Verbindungsaufbau
dauerte höchstens 20 Minuten.
Meist bricht die Verbindung aber schon nach ein bis zwei Minuten ab.
Der Bluetooth Lautsprecher steht im Umkreis,
höchstens einen Meter vom Raspi entfernt.

Ich habe diesen Lautsprecher erst vor Kurzem geschenkt bekommen und sonst
nix, womit ich Bluetoothverbindungen testen könnte.
Daher mal allgemein die Frage, ob Bluetoothlautsprecher überhaupt das Wahre sind,
wenn man z.B. kontinuierlich Hintergrundmusik hört.
Hier ist über Bluetooth auch ne ganze Menge los, wenn der Raspi durch die Gegend scannt.
Mindestens drei Geräte, die sich nicht in dieser Wohnung befinden sehe ich immer,
ab und zu ne Smartwatch und weiß der Himmel, was die Leute im Umkreis noch so funken lassen.
Vlt. spielt das auch ne Rolle?

Ich muß nochmal nachfassen

Quote

Was rufst du da genau wie auf?

Ich rufe das Programm "guvcview" auf!

Und wie genau:
Indem ich es entweder in einer unter X gestarteten Shell (wahlweise: xterm oder lxterminal)mit > "guvcview" [Ret]
aufrufe, oder mit der Maus im Programmenü 1x anklicke.
Letzteres muß ich wohl nicht genauer beschreiben?
Das macht beides dasselbe, bis auf das ich, wenn ich es aus der Shell starte,
die Fehlerausgabe des Programmes in selbiger beobachten kann,
während es läuft.

Das hier:

Quote

Ein Update ist bei einem funktionierendem geschlossenem System nie notwendig.

... ist mir neu, um nicht zu sagen "fremd".

Na,
ich zieh mir erstmal das letzte Image, schreibs auf die Karte,
fahre dann damit den Raspi hoch.
Nach den Einstellereien mit raspi-config kriegt pi erstmal ein anderes password und root überhaupt eins.
Danach gibts prinzipiell als root ein "apt-get update" und dann ein "apt-get upgrade".
Letzteres mache ich als root so jede Woche mal.

Diese erwähnten *.mkv-Dateien habe ich mir mit VLC auf meinem Großen mal angeguckt,
man hört nur den Ton, ein Bild erscheint nicht.
vlc hatte ich früher mal auf dem Raspi probiert, aber das war zum einen ein riesiger Softwareklotz
und zum zweiten lief das im Verhältnis zum omxplayer unglaublich zäh
und so habe ich keine Lust mir die Karte damit nochmal zuzukleistern,
obwohl ichs schade finde, da VLC ja eigentlich alles könnte, was ich möchte.
Deswegen war ich froh, guvcview für die Kammeras gefunden zu haben,
was Anfangs ja auch brav lief .
Da zeigte es mir sogar die Audioaussteuerung im Monitorbild bei der Aufnahme.
Jetzt steht das Monitorbild bei der Aufnahme, und ein Videobild wird offensichtlich nicht aufgenommen, egal,
was ich in der GUI einstelle und gespeichert wird nurnoch *.mkv.

Hi,
ich hoffe, daß sich hier jemand etwas mit Videoaufnahmen auf dem Raspi beschäftigt hat
und mir weiterhelfen kann:
Ich habe hier 2 USB-Webcams, die Anfangs, als ich "guvcview" unter raspbian- "Pixel"
auf nem Raspberry Pi 3b installiert hatte zwar zäh, aber einigermaßen funktionierten.
Nun stürzt das Programm, aus mir unerfindlichen Gründen ständig ab und Aufnahmen
macht das Ding nurnoch mit irgendnem "matroska-codec".
Es spuckt *.mkv -Dateien bei der Aufnahme aus, egal welchen Codec ich in der GUI wähle.

Ich habe das Programm nun aus der Kommandozeile gestartet
und wie es scheint, versucht V4L_2CORE da irgendwas mit diesem "matroska-codec" zu veranstalten,
obwohl ich im Programm mpg1-Kodierung ausgewählt habe:

Folgendes ist der Inhalt der Datei [Zuhause]/.config/guvcview2/video0

Ich les da nirgendwo was von "matroska",
obwohl ich -wie gesagt- meine, daß das Anfangs, nach der Installation von guvcview,
sogar als Auswahl für nen Codec in der GUI vorhanden war.

Hab ich da irgend ne Verschlimm-Besserung geupdatet?
Mir ist nun gesagt worden, daß man kein dist-upgrade
oder raspi-update mehr machen soll,
aber "apt-get update", "apt-get upgrade" -ist das noch erlaubt?

Neues Image -neues Glück!
Et pfundste! -erstmal
und das Gerät meldete sich sogar mit "Your device is connected."
Aber sehr zuverlässig ist es nicht.
Die Verbindung brach mehrmals nach einigen Minuten ab,
obwohl die Lautsprecher nur etwa 30cm vom Raspi entfernt stehen.
Aber ich freue mich, daß es überhaupt funktioniert.
:)