Raumfeld - 3rd-Party Entwickler

Gibt es irgendwelche Dokumente die du/ihr 3rd Party Entwicklern zur Verfügung stellen wollt/könnt?

Für welche Plattformen ist eure PC-Software gedacht und in welcher Programmiersprache habt ihr diese geschrieben?
Besteht die Möglichkeit diese durch Plugins zu erweitern?

Jetzt brauche ich nur noch ein Raumfeld System zum Entwickeln. =)

thecutter schrieb:

Gibt es irgendwelche Dokumente die du/ihr 3rd Party Entwicklern zur Verfügung stellen wollt/könnt? Für welche Plattformen ist eure PC-Software gedacht und in welcher Programmiersprache habt ihr diese geschrieben? Besteht die Möglichkeit diese durch Plugins zu erweitern? Jetzt brauche ich nur noch ein Raumfeld System zum Entwickeln. =)

Hi,

Raumfeld selbst hat noch keine Dokumente, die wir hier veroeffentlichen koennten. Wir haben uns aber bei der Implementierung eng an den DLNA Standard gehalten. Den kann man im Netz nachlesen, zum Beispiel hier:

http://www.linkpdf.com/ebook-viewer.php

(Dort dann zum Beispiel nach "AVTransport", "RenderingControl" suchen.)

DLNA setzt auf UPnP auf. UPnP beschreibt, wie Devices und Services, Funktionen und Variablen sich zu beschreiben haben und zu benutzen sind. DLNA beschreibt eine bestimmte Menge von solchen Devices, von denen wir im Wesentlichen die Folgenden nutzen:

urn:schemas-upnp-org:device:MediaRenderer:1
urn:schemas-upnp-org:device:MediaServer:1

Der DLNA Standard gibt die Services vor, die von Devices dieser Klassen angeboten werden muessen. Zu den Devices und Services gibt es bis ins kleinste Fizzelchen ausdokumentierte Beschreibungen als pdf im Netz.

Undokumentiert sind die UPnP-Devices RaumfeldDevice und ConfigDevice. Sie beschreiben sich ein wenig selbst durch sinnvolle Funktionsnamen. Es gibt aber leider noch keine Prosa dazu.

PC-Software gibt es von Raumfeld noch gar nicht. Wenn wir die angehen, werden wir versuchen alle Plattformen zu unterstuetzen und bei den Sprachen wahrscheinlich einen Mix aus C/C++ und Webtechnologien waehlen. Das ist aber noch vollkommen unklar.
PlugIns sehe ich in der PC-Software eher nicht. Ich wuerde eine Erweiterbarkeit auf UPnP-Basis sinnvoller finden. Eventuell durch einen von uns definierten und von Euch implementierten Service, der dann vom Raumfeld-System eingebunden wird.

Gruss, Henry

Leider funktioniert der Link von dir nicht.

Danke für die Infos!

Ich hatte irgendwo gehört das es eine interne Software gibt, die schon getestet wird bei euch.
Aber ok, dann ist da ja noch alles offen, wenn es keine gibt. =)

Werde mich die Tage schonmal mit UPnP/DLNA beschäftigen und die benötigten Komponenten bei euch bestellen.

Ah, ein Entwickler-Thread.
Da fühle ich mich wohl.

Als Starthilfe mit UPnP will ich kurz (m)ein fertiges Projekt vorstellen.
Daran sollte sich einiges Ablesen lassen, da es ja eben UPnP ist und damit weitgehend unabhängig vom Musikwiedergabekästchen auf der anderen Seite.

Es handelt sich um einen Mikrocontroller mit Infrarot-Empfänger, der über Ethernet SOAPtechnisch mit Sonos ZonePlayern kommuniziert.

Ist bei mir im Schlafzimmer im Einsatz, um bestimmte Aktionen mit einer Standard-IR-Fernbedienung auslösen zu können, die sonst über das Menü des Original-Controllers nur umständlich zu erreichen sind (siehe unten).
Ursprünglich wollte ich nur beim Film gucken die Lautstärke steuern, ohne von der Universal-IR-Fernbedienung auf den Original-Controller wechseln zu müssen.
Wurde dann etwas mächtiger.


Hardware:
http://arduino.cc mit Ethernet-Shield.
Zusammen 50 bis 60 Euro und ein paar Cent für einen TSOP4838 oder ähnlich.

Hier der Code, auf den meine Version aufsetzt:
https://github.com/jpmens/sonospauseIR/blob/RC5/sonospauseIR.pde

"loop ()" ist die Funktion, die ständig in Schleife durchlaufen wird.
"setup ()" wird einmal nach dem "Booten" durchlaufen.

An den "#define SONOS_" sieht man ja den Funktionsumfang.

Bei mir kamen als "ein Tastendruck-Aktionen" noch dazu:
- Umschaltung auf Line-In beliebiger Zonen
- Verknüpfung mit der Küchen-Zone (Wecker dorthin mitnehmen)
- Ebenso trennen von allen anderen Zonen
- Equalizer-Presets (mehr Bass bei Filmbetrieb, Sweetspot mittels Balance an belegte Bettseite(n) anpassen, ...)
- Sleeptimer
- Lautstärkebegrenzer
- "Alles Stop" als Sicherheits- bzw. Faulheitsförderungsfunktion beim Verlassen der Bude
//edit: Und meine Radiosender-Favoriten wurden in eine Playlist geschoben, um die URLs aus dem Quelltext wegzukriegen.


Fragen dürfen auch an mich gestellt werden, damit Henry nicht ganz alleine ist.

Gruss
Jochen

Wenig los hier...
Wo sind die ganzen feature-wütigen Hobbyisten?

Ich baue mir jetzt noch eine intelligentere Lautstärkeregelung:
Derzeit ändert jeder Tastendruck den Pegel um 5%, angelehnt an die Original-Controller.
Das ist manchmal etwas zu grob, gerade wenn man relativ leise hört.
Werde es nun so machen, dass der erste Lautstärkeregelungsbefehl innerhalb eines Zeitfensters (eine Sekunde) nur 2% ändert; jeder andere wieder die vollen 5%, solange es in die selbe "Richtung" geht.

Gruss
Jochen

Hallo zusammen

Bin derzeit am Multiroom-Systeme evaluieren.

Grundsätzlich tendiere ich zu offenen Systemen (Raumfeld), allerdings finde ich nirgends eine aktive Entwickler-Community oder eine entsprechende SDK... Ohne diese Basis macht auch OpenSource nicht wirklich viel Sinn...

Gibts hier eventuell andere Foren, wo entsprechende Themen diskutiert werden? Herr Raumfeld? :-)

Danke für Eure Hilfe!

zwergholdrio schrieb:

Grundsätzlich tendiere ich zu offenen Systemen (Raumfeld), allerdings finde ich nirgends eine aktive Entwickler-Community oder eine entsprechende SDK... Ohne diese Basis macht auch OpenSource nicht wirklich viel Sinn...

Ich hatte eigentlich vor, vorerst dieses Forum zum Austausch mit 3rd-Party-Entwicklern zu gebrauchen. Die Resonanz ist aber, wie man sieht, nicht besonders hoch. Es gibt kein SDK oder aehnliches zum Erweitern von Raumfeld-Produkten. Die Idee ist eher, eigene Software zu schreiben, die mit den bestehenden Raumfeld-Services interagiert.

Software, die wegen des Copyleft der GPL veroeffentlicht werden muss oder benoetigt wird, um eigene Software auf die Geraete zu spielen (Boot-Loader), findet sich hier: http://www.teufel.de/raumfeld-open-source.html. Der restliche Raumfeld-Software-Stack ist aber kein Open-Source! Raumfeld ist ein offenes System in dem Sinne, dass es offene Standards benutzt, nicht, dass unsere Software oeffentlich entwickelt wird.

Unser Open-Source-Beitrag ist vor allem, dass Bug-Fixes und Verbesserungen an von uns benutzten Open-Source-Projekten direkt zurueck an die jeweiligen Maintainer fliessen.


Gruss, Henry

Hallo,
der ebook-Link funktioniert leider nicht.
Da ich selber die Raumfeldproduktlinie noch nicht getested habe, weiss ich noch nicht welche Audioformate der Renderer unterstützt. Kannst du uns noch mehr Details(welcher Mikrocontroller, mit oder ohne OS ...) über eurer Renderer und Controller verraten.

Engel_Hi schrieb:

der ebook-Link funktioniert leider nicht.

Er fuehrt zu einer ebook-suche - dort kann man dann z.B. nach "AVTransport" siuchen - ich habe es gerade eben getan und es hat funktioniert.

Wie auch immer, die tatsaechlich benutzte Hardware sollte keine Rolle spielen. Die Geraete geben mittels UPnP-Funktionen Auskunft ueber alle wissenswerten Details, inklusive der unterstuetzten Protokolle und Formate.

Wenn Du konkrete Fragen hast, kann ich Dir aber gern auch Details zum Prozessor usw verraten. Um auf Verdacht und ohne ersichtlichen Grund ein komplettes Datenblatt zu erstellen, fehlt mir jetzt aber die Zeit.

Gruss, Henry

ich glaube ich habe noch nicht verstanden worum es hier geht. Wollt ihr, dass wir die Raumfeldprodukte als so einer Art Entwicklungsboard benutzen und direkt dort rumprogrammieren oder wollt ihr dass wir einen anderen Plattform(PC, Smartphone oder selbstentwickeltes Gerät) benutzen?
Gruß

Letzteres.
Für das andere sind die Mitarbeiter zuständig.

Henry_Raumfeld schrieb:

Wie auch immer, die tatsaechlich benutzte Hardware sollte keine Rolle spielen. Die Geraete geben mittels UPnP-Funktionen Auskunft ueber alle wissenswerten Details, inklusive der unterstuetzten Protokolle und Formate.

Weshalb man auch kein SDK braucht.

Die notwendigen Tools sind die gleichen wie bei anderen Geräten, die auf UPnP aufsetzen.
Alles gleich offen, sozusagen.

Gruss
Jochen

Master_J schrieb:

Letzteres. Für das andere sind die Mitarbeiter zuständig.

Schade, das andere wäre mir lieber gewesen.

Hallo Henry,

Ich habe das 1RaumfeldS. Bei allen von mir evaluierten MediaServern ist mir aufgefallen, dass im ContentDirectory das searchable property nicht gesetzt/vorhanden ist.
Jetzt scheint bei Abwesenheit der Raumfeld Base ein MediaRenderer die vorhandenen MediaServer zu scannen und den Content als MediaServer bereitzustellen, um in der erstellten Datenbank dann mit dem Controller suchen zu können.

Meine konkrete Frage:
Was muss ein MediaServer mitbringen, damit der Raumfeld Controller das Indizieren nicht einleiten muss und direkt den Content sieht und durchsuchen kann?

Master_J schrieb:

Hardware: http://arduino.cc mit Ethernet-Shield.

Oh, ich sehe gerade, dass es das jetzt auch zusammen auf einer (1) Platine gibt und sogar PoE möglich ist:
http://arduino.cc/en/Main/ArduinoBoardEthernet
Macht die ganze Sache noch etwas kompakter und microSD ist auch noch mit dabei.

Man muss sich aber immer bewusst sein, dass so ein ATmega328 mit seinen 2 kB SRAM schon sehr knapp dimensioniert ist, bei dem String-Aufkommen für diesen Zweck.
Machbar ist es, aber für den "experimentierfreudigen Einsteiger" würde ich eine Nummer grösser empfehlen.

BTW: Gibt es ausser mir (und den bestenfalls 10 Leuten in anderen Foren weltweit) noch jemanden, der von extern die "Offenheit" solcher Systeme ausnutzt?
Kommt mir manchmal vor wie rund um "Open Source Anwendungen", wo jedem superwichtig ist, den Quelltext sehen zu können - aber keiner tut es...

Gruss
Jochen

blameless schrieb:

Was muss ein MediaServer mitbringen, damit der Raumfeld Controller das Indizieren nicht einleiten muss und direkt den Content sieht und durchsuchen kann?

Das ist so nicht vorgesehen. Der Controller zeigt immer nur den Content des Raumfeld MediaServer an. Dieser aggregiert verschiedene Quellen (USB-Platte, Netzlaufwerke und andere UPnP MediaServer).

Henry_Raumfeld schrieb:

zwergholdrio schrieb: Grundsätzlich tendiere ich zu offenen Systemen (Raumfeld), allerdings finde ich nirgends eine aktive Entwickler-Community oder eine entsprechende SDK... Ohne diese Basis macht auch OpenSource nicht wirklich viel Sinn... Ich hatte eigentlich vor, vorerst dieses Forum zum Austausch mit 3rd-Party-Entwicklern zu gebrauchen. Die Resonanz ist aber, wie man sieht, nicht besonders hoch. Es gibt kein SDK oder aehnliches zum Erweitern von Raumfeld-Produkten. Die Idee ist eher, eigene Software zu schreiben, die mit den bestehenden Raumfeld-Services interagiert.

Hallo Henry,

finde diesen Thread gerade erst (wieder).

Was ich nicht ganz verstehe ist, was die 3rd-Party-Entwickler denn genau mit dem Raumfeld tun können, wenn es weder eine API noch eine veröffentlichte Software gibt.

Du sagst, die Resonanz sei nicht große, aber nachdem ich nicht erkennen kann, was ich als 3rd-Party-Entwickler _überhaupt_ zum Raumfeld-System beitragen könnte, ist das doch auch nicht verwunderlich, oder?

Wenn Raumfeld nur DLNA-Funktionalität als Schnittsette anbietet, würde ich erwarten, dass ich keine weiteren Informationen brauche und einfach DNLA-Software entwickle.

Habe ich irgend etwas übersehen?

P.S.: Der Link zu Eurer GPL-Software ist übrigens inzwischen tot.

coolio107 schrieb:

Was ich nicht ganz verstehe ist, was die 3rd-Party-Entwickler denn genau mit dem Raumfeld tun können, wenn es weder eine API noch eine veröffentlichte Software gibt. Du sagst, die Resonanz sei nicht große, aber nachdem ich nicht erkennen kann, was ich als 3rd-Party-Entwickler _überhaupt_ zum Raumfeld-System beitragen könnte, ist das doch auch nicht verwunderlich, oder? Wenn Raumfeld nur DLNA-Funktionalität als Schnittsette anbietet, würde ich erwarten, dass ich keine weiteren Informationen brauche und einfach DNLA-Software entwickle. Habe ich irgend etwas übersehen?

Nein, genau wie Du es beschreibt, war es gedacht: Das System offeriert mehrere BlackBoxes (MediaServer, Zones als virtuelle Renderer usw) die sich, quasi selbst-dokumentierend, ueber UPnP ansteuern lassen. Als 3rd-Party Entwickler kann man nun z.b. Control-Points bauen, die auf Plattformen laufen, die Raumfeld noch nicht unterstuetzt, etwa Windows, Mac, BlackBerry, Symbian. Man kann genauso gut die oft gewuenschte Funktionalitaet des Weckers oder Sleep-Timers extern implementieren, beispielsweise als Android-Service, der das Raumfeld steuert.

Mit etwas Phantasie laesst sich da einiges tun, es ist unserer Meinung nach dazu nicht unbedingt notwendig, unsere Software offenzulegen, da eine sehr einfach benutzbare und stabile UPnP-API existiert.

Gruss, Henry

Henry_Raumfeld schrieb:

Mit etwas Phantasie laesst sich da einiges tun, es ist unserer Meinung nach dazu nicht unbedingt notwendig, unsere Software offenzulegen, da eine sehr einfach benutzbare und stabile UPnP-API existiert.

Ist ja schon OK, wollte ich ja nicht kritisieren. Ich hatte mich nur gewundert, dass Du Dich obdessen über die mangelnde Nachfrage wunderst. Wenn's eh nix Raumfeld-spezifisches zu diskutieren gibt, dann fragt natürlich auch keiner

Der Offenlegungs-Link fehlt aber trotzdem. Stört mich nicht, wollte nur drauf hinweisen, bevor Ihr Ärger mit einem Rechteinhaber bekommt, ist machmal etwas kribbelig, bei dem GPL-Zeugs.

coolio107 schrieb:

Der Offenlegungs-Link fehlt aber trotzdem. Stört mich nicht, wollte nur drauf hinweisen, bevor Ihr Ärger mit einem Rechteinhaber bekommt, ist machmal etwas kribbelig, bei dem GPL-Zeugs.

Meinst Du http://www.teufel.de/raumfeld-open-source.html ? Falls es Webseiten gibt, die ins Leere linken, sag uns bitte die URL der Seite, damit wir das Problem beheben können.

Ja, die meinte ich.
Der Link, den Henry weiter oben verlinkt hat, führt ins Leere, weil da ein "." hinten dran steht. Sorry, hatte ich gestern übersehen.
Solltet Ihr aber mal korrigieren (in dem Post), bin bestimmt nicht der einzige, der drauf 'reinfällt, man klickt halt eher auf Links und den Punkt in der URL übersieht man leicht.

Freigabe für USB-Platte/Stick an der Base

Bislang werden ja per USB an die Base angeschlossene Laufwerke nicht als Share (SMB) freigegeben.
Dank ssh-Zugang zur Base (erhältlich per PM bei den RF-Jungs, oder bei mir) lässt sich das aber recht einfach nachrüsten.
Allerdings müsste man das nach einem Update wiederholen...
Das Ganze natürlich ohne Gewähr etc. - ein echtes Risiko besteht m.E. aber nicht, da man auch im schlimmsten Fall imer neu flashen kann.

Die Base erleichtert die Sache dadurch, dass bereits das Tool "usbmount" benutzt wird - es müssen lediglich 2 weitere Hook-Scripts abgelegt werden, hier in der Variante "nicht schön, aber tut's für mich"

Hinweis: die 'Singlequotes' unten sind die 'Akzentzeichen' links neben 'Backspace', mit 'Shift' gedrückt.

1) "10share-usb" in /etc/usbmount/mount.d:

#!/bin/sh
# Check if this is the master device
grep "^ismaster=yes" /var/raumfeld-1.0/master-process.conf || exit 0
DEV=`basename $UM_DEVICE`
DIR=`dirname $UM_MOUNTPOINT`
SMBPID="/var/run/smbd.pid"
SMBINC="/etc/samba/usb-smb-${DEV}.conf"
SMBCFG="/etc/samba/smb.conf"
chmod 755 $DIR
cat << EOT > $SMBINC
[Music-on-USB-${DEV}]
path = $UM_MOUNTPOINT
public = yes
only guest = yes
writable = yes
printable = no
browseable = yes
available = yes
EOT
# evtl. Reste loeschen
sed -i -e "s|include = ${SMBINC}||g" $SMBCFG
# share eintragen
echo "include = ${SMBINC}" >> $SMBCFG
# config aktivieren
kill -HUP `cat $SMBPID`


2) "45unshare-usb" in /etc/usbmount/umount.d:

#!/bin/sh
# Check if this is the master device
grep "^ismaster=yes" /var/raumfeld-1.0/master-process.conf || exit 0
DEV=`basename $UM_DEVICE`
SMBPID="/var/run/smbd.pid"
SMBINC="/etc/samba/usb-smb-${DEV}.conf"
SMBCFG="/etc/samba/smb.conf"
# deactivate share
echo "#" > $SMBINC
sed -i -e "s|include = ${SMBINC}||g" $SMBCFG
kill -HUP `cat $SMBPID`


Nicht getestet habe ich USB-Platten/Sticks mit mehr als einer Partition. Sofern "usbmount" aber richtig funktioniert, sollte das eigentlich auch klappen.
Sollten durch unsaubere Unmounts oder so doch noch "include"-Reste in der smb.conf übrig bleiben, werden die vom smb Prozess einfach ignoriert.

Hallo Henry,

du hast hier im Forum mal darauf verwiesen, das eure Systeme auf buildroot aufsetzen und unter Teufel Opensource alles zur Verfügung gestellt wird um Änderungen am Buildroot vorzunehmen. Ich habe mir das mal angesehen kann aber das Buildroot zur Base nicht finden.

Ich würde gerne das Buildroot neu erzeugen (z.B. ohne 3DNOW support) und versuchen die Base unter VMWare ESXi zu virtualisieren. (Buildroot x86 generisch compilieren, ESXi Netzwerk Treiber einbinden, /raumfeld aus Base Image "as is" einbinden, Init Scripte ggf. anpassen) Wie steht Ihr hierzu ? Unterstützt Ihr die Idee ? Könnte das ein Weg sein oder scheitert das daran das eure proprietären Programme analog zur Buildroot CPU spezifisch compiliert wurden (Thema 3DNow).

Gruß,

Uwe

mystream schrieb:

Ich würde gerne das Buildroot neu erzeugen (z.B. ohne 3DNOW support) und versuchen die Base unter VMWare ESXi zu virtualisieren. (Buildroot x86 generisch compilieren, ESXi Netzwerk Treiber einbinden, /raumfeld aus Base Image "as is" einbinden, Init Scripte ggf. anpassen) Wie steht Ihr hierzu ? Unterstützt Ihr die Idee ? Könnte das ein Weg sein oder scheitert das daran das eure proprietären Programme analog zur Buildroot CPU spezifisch compiliert wurden (Thema 3DNow).

Wir verwenden für Raumfeld 1.7 das buildroot Release 2011.08 (siehe http://buildroot.uclibc.org/downloads/). Gerne können Dir gerne eine buildroot Konfiguration zur Verfügung stellen. Allerdings wird das Ganze wohl daran scheitern, dass Teile der Raumfeld Software nicht im Source Code zur Verfügung stehen und deshalb auf einem System, welches auf einer anders konfigurierten Toolchain beruht, nicht laufen werden. Vielversprechender wäre wohl der Ansatz die VM so zu konfigurieren, dass das Base System ohne Anpassungen läuft.

Hallo,

ich stimme Dir zu. Den Versuch das Image der Base in einer VM zu booten habe ich schon hinter mir. Der x86 Kernel ist aber leider für AMD 3dnow kompiliert. Beim Versuch den zu booten kommt das die HW kein 3dnow unterstützt. (Mein ESXi Server ist intel basiert). Deshalb wollte ich zunächst das Buildroot Image für "i86 generic" ohne spezielle CPU Optimisierungen übersetzen. Meine Annahme ist, das wenn ich eure Konfig verwende ich am Ende ein Image habe das identisch zu eurem übersetzt wurde mit dem Unterschied das die Binaries auf AMD & intel x86 gleichermasen laufen sollten. Bleiben eure closed source Programme die ich nicht neu übersetzen kann. Hier ist aus meiner Sicht entscheidend ob die auch speziell für AMD/Geode übersetzt wurden oder für x86 generisch. In letzterem Fall würde ich annehmen das ich Sie 1:1 in mein VM Image kopieren könnte. In ersterem denke ich hast du recht.

Wie compiliert Ihr auf Anwendungsebene ? Nutzt Ihr die AMD Befehlssatzerweiterungen ? Ein "file config-service" lässt mich hier zumindest hoffen das nicht. -> config-service: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Kann ich eure Konfig bekommen ? (In der Hoffnung das Ihr den closed source x86 generisch übersetzt habt)

Habe ich was übersehen ?

Gruß

mystream schrieb:

Den Versuch das Image der Base in einer VM zu booten habe ich schon hinter mir. Der x86 Kernel ist aber leider für AMD 3dnow kompiliert. Beim Versuch den zu booten kommt das die HW kein 3dnow unterstützt. (Mein ESXi Server ist intel basiert). Deshalb wollte ich zunächst das Buildroot Image für "i86 generic" ohne spezielle CPU Optimisierungen übersetzen. Meine Annahme ist, das wenn ich eure Konfig verwende ich am Ende ein Image habe das identisch zu eurem übersetzt wurde mit dem Unterschied das die Binaries auf AMD & intel x86 gleichermasen laufen sollten. Bleiben eure closed source Programme die ich nicht neu übersetzen kann. Hier ist aus meiner Sicht entscheidend ob die auch speziell für AMD/Geode übersetzt wurden oder für x86 generisch. In letzterem Fall würde ich annehmen das ich Sie 1:1 in mein VM Image kopieren könnte. In ersterem denke ich hast du recht. Wie compiliert Ihr auf Anwendungsebene ? Nutzt Ihr die AMD Befehlssatzerweiterungen ? Ein "file config-service" lässt mich hier zumindest hoffen das nicht. -> config-service: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Kann ich eure Konfig bekommen ? (In der Hoffnung das Ihr den closed source x86 generisch übersetzt habt)

Ich würde an Deiner Stelle mal versuchen, nur den Kernel zu ersetzen. Den Userspace für eine andere Zielplatform neu zusammenzubauen halte ich für deutlich zu komplex und wenig erfolgversprechend. Mit ein bisschen Glück genügt es aber, wenn Du nur den Kernel durch einen ersetzt, der zu Deiner virtuellen Maschine kompatibel ist.

Alles in allem stehe ich diesem Versuch eher skeptisch gegenüber. Insbesondere sehe ich da Support-Aufwand auf uns zukommen, den ich nicht verantworten kann. Andererseits ist es natürlich ein interessantes Experiment.

So, nun aber....
Allmählich nimmt mein Project "StereoAnlage raus - Raumfeld rein" konkrete Formen an. Ziel ist es, das altterwürdige 43cm Rack mit Accuphase Amp, Yamahe CD, Tuner und Technics Schallplettenspieler (und natürlich Connector) zu minimalisieren, wobei die Wiedergabe von CDs und Schalplatte aber weiterhin gegeben sein soll.

Als Phase 1 wird einfach ein Class D Amp Modul mit Lautstärke/Klang/Loudness versehenund in einem micro S1 von hfx mit dem Connector verheiratet. Was mir allerdings vorschwebt ist ein wesentlich integrierteres System, in dem ein USB Interface als Signalknoten dient. Damit hätte ich dann Anschluß für Phono und CD und der schmerzlich vermisste Kopfhörerverstärker ist auch gleich dabei. Leider läßt sich so entweder Phono und CD nicht streamen (Base Output an USB Pre Input), oder der KH Ausgang fällt für's Raumfeld flach (USB Pre Out an Connector In).So reifte in mir die Überlegung das Interface direkt per USB an's Raumfeld anzubinden.Ganz genial wäre es, wenn nicht nur die Wiedergabe über USB klappen würde würde, sondern der Eingang wie der LineIn des Connectors zur Wiedergabe übers Netzwerk genutzt werden könnte.

Erste vorsichtige Anfragen wurden von Euch Raumfeldern ja dahingehend beantwortet, dass die Anbindung eines USB Audio Interfaces wohl am einfachsten/nur an der Base zu bewerkstelligen wäre. Nachdem die Platine der Base mit ihrem Footprint exzelent in das ITX Gehäuse von hfx passt, eine super Idee, das System noch weiter einzudampfen und auch den Server selber zu integrieren. Mit jlegs Script die USB Platte per SMB freizugeben, hätte man so eine sehr kompakte Medienzentrale.

So weit so gut - allerdings bietet die Base ja nicht die Option der Wiedergabe, so dass die Frage bleibt, wie es mit dem USB Interface dann weitergeht. Wichtig ist, anzumerken, dass ich natürlich ausschließlich von Class kompatiblen USB Audiointerfaces rede, die ohne proprietäre Treiber auskommen. In meinem Fall wäre es das USB Pre2 von Sound Devices, interessant wären aber aber auch der RipAmp etc.

Bevor ich mich nun komplett versteige: bestünde tatsächlich die Möglichkeit, ein an der Base gemountetes Audio Interface als solches zu nutzen? Ersteres sollte ja nicht all zu schwer sein. Für Letzteres müsste die Base doch allerdings (von Euch) um ein Client Modul erweitert werden, oder?

quadrophoeniX schrieb:

Erste vorsichtige Anfragen wurden von Euch Raumfeldern ja dahingehend beantwortet, dass die Anbindung eines USB Audio Interfaces wohl am einfachsten/nur an der Base zu bewerkstelligen wäre.

Wurden sie? Auf der Base ist keine Infrastruktur zum Betrieb als Renderer, also Abspielgeraet, vorhanden. Es ist auch von unserer Seite nicht vorgesehen USB-Audioadapter zu unterstuetzen. Wir sehen die Base als reinen Server, der neben dem Router, also ausserhalb des Wohnbereichs, positioniert wird. Unterstuetzung von USB Audio Interfaces wuerde fuer uns vermutlich einen erheblichen Supportaufwand bedeuten. Diese Zeit wollen wir lieber in Features stecken, die einem breiteren Kundenkreis zugute kommen.

Bei aller Skepsis, interessant ist der Ansatz aber natuerlich schon. Ich werde das mal zur Sprache bringen, vielleicht entwickelt sich ja aus der Idee ja doch was...

sven_raumfeld schrieb:

Wurden sie?

Ja, wurden sie. Damals ging es aber lediglich um die theoretische Möglichkeit, Treiber einzubinden. Leider speichert das Forum die PMs aber nicht so lange. Ist aber auch egal, denn wie ich ja schon vermutete, ist auf der Base

sven_raumfeld schrieb:

keine Infrastruktur zum Betrieb als Renderer, also Abspielgeraet, vorhanden.

Daher werde ich dem Connector einfach einen separaten KH Verstärker spendieren und warte in Ruhe ab, was Ihr in Zukunft vielleicht so alles aus dem Ärmel schüttelt, denn

sven_raumfeld schrieb:

interessant ist der Ansatz aber natuerlich schon. [...] vielleicht entwickelt sich ja aus der Idee ja doch was...

Das Projekt nimmt allmählich konkrete Formen an - RIAA Filter ist dimensioniert, KH Verstärker aufgebaut und für gut befunden. Ich denke, die "Kiste" wird richtig toll. Mittlerweile ist das Signalrouting auch komplett durchstrukturiert und zum ganz großen Glück fehlt mir nur eine winzige Information und eventuell ein klitze-kleines Bau-/Ersatzteil. Deswegen frage ich hier einfach sehr vorsichtig nach, ob jemand der Raumfelder und wenn ja wer, mir eine (wirklich nur eine) Frage bezüglich der Hardware des Connector geben kann. Ich möchte hier nicht in's Detail gehen und gebe mein allergrößtes Ehrenwort, dass dies definitiv NICHT in eine supportaufwändige Geschichte rauslaufen wird - eine Frage und Schluß. In diesem Sinne hoffe ich auf eine PM.

sven_raumfeld schrieb:

mystream schrieb: Den Versuch das Image der Base in einer VM zu booten habe ich schon hinter mir. Der x86 Kernel ist aber leider für AMD 3dnow kompiliert. Beim Versuch den zu booten kommt das die HW kein 3dnow unterstützt. (Mein ESXi Server ist intel basiert). Deshalb wollte ich zunächst das Buildroot Image für "i86 generic" ohne spezielle CPU Optimisierungen übersetzen. Meine Annahme ist, das wenn ich eure Konfig verwende ich am Ende ein Image habe das identisch zu eurem übersetzt wurde mit dem Unterschied das die Binaries auf AMD & intel x86 gleichermasen laufen sollten. Bleiben eure closed source Programme die ich nicht neu übersetzen kann. Hier ist aus meiner Sicht entscheidend ob die auch speziell für AMD/Geode übersetzt wurden oder für x86 generisch. In letzterem Fall würde ich annehmen das ich Sie 1:1 in mein VM Image kopieren könnte. In ersterem denke ich hast du recht. Wie compiliert Ihr auf Anwendungsebene ? Nutzt Ihr die AMD Befehlssatzerweiterungen ? Ein "file config-service" lässt mich hier zumindest hoffen das nicht. -> config-service: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Kann ich eure Konfig bekommen ? (In der Hoffnung das Ihr den closed source x86 generisch übersetzt habt) Ich würde an Deiner Stelle mal versuchen, nur den Kernel zu ersetzen. Den Userspace für eine andere Zielplatform neu zusammenzubauen halte ich für deutlich zu komplex und wenig erfolgversprechend. Mit ein bisschen Glück genügt es aber, wenn Du nur den Kernel durch einen ersetzt, der zu Deiner virtuellen Maschine kompatibel ist. Alles in allem stehe ich diesem Versuch eher skeptisch gegenüber. Insbesondere sehe ich da Support-Aufwand auf uns zukommen, den ich nicht verantworten kann. Andererseits ist es natürlich ein interessantes Experiment.

Die Idee die Base in einer VM laufen zu lassen finde ich großartig!

@mystream: Bist du da noch dran?
@jleg: Ich würde mich gerne auch mal versuchen und hätte dazu auch gerne ssh Zugriff, wie bekomme ich den?

hush-developer schrieb:

Die Idee die Base in einer VM laufen zu lassen finde ich großartig! @mystream: Bist du da noch dran?

Ja. Ich habe seit etwa 1 Woche meine virtualisierte Base in Betrieb.
Aktuell mangels Masse noch nur mit einem Paar Speaker-M ohne Multiroom.

Die Idee die Base in einer VM laufen zu lassen finde ich großartig! @mystream: Bist du da noch dran?

Das finde ich auch toll! Ich bin nämlich gerade dabei alles was so einzeln in meinem Netzwerk rumhängt in ein Gerät zu packen und alles über eine ZOTAC ZBOX (Windows) laufen zu lassen. Wäre natülich ziemlich genial wenn ich die Base einmotten könnte. würde der Performance beim Titel-Suchen vermutlich auch nen Schub geben

@mystream
@hush-developer

Könnt Ihr mir ein paar Tips geben wie ich die Base Virtualisieren kann?

DANKE!

Genau! Und ist es von Vorteil, eine Zacate Plattform zu nehmen, die unterstützt doch 3Dnow! ?

Eine virtualisierte Base auf ESXi würde mich auch sehr interessieren.
Mein ESX-Server ist mein einziges "immer an" Gerät, deshalb wäre
es echt klasse, wenn das legal möglich wäre.
2 Fragen. Lohnt die Zeit es zu versuchen, geht es?
Wenn jemand ein paar Tips hat wäre das natürlich super.

Juhuu, meinehttp://www.solid-run.com/products/cubox]SolidRun CuBox ist jetzt unterwegs! vor der NAB wird's aber wohl nix mehr, wird wohl also eher Pfingsten...

Seht Ihr - damit meine ich vor Allem myStream - eine Möglichkeiut die Base darauf zu virtualisieren? Ansonsten wird darauf einfach ein Linux mit Foobar und UPnP Plugin installiert und sie kommt in meine eierlegende Wollmilchsau (Connector Platine, mit PCM 2906 und KHV aufgebohrte ProJect PhonoBox V und IcePower Amp im HFX minitITX Gehäuse) ...

Hallo quadrophoenix,

die Base auf einer CuBox wirst du nicht zum laufen bringen. In der CuBox werkelt ein Prozessor mit ARM Architektur. In der Base einer aus der x86 Welt. Damit hast du eine völlig andere Architektur. Wenn du auf dieser versuchst einen Prozessor Emulator wie QEMU an den Start zu bringen der dir auf ARM x86 Binaries dynamisch emuliert wirst du spätestens wenn es Dir gelingt und du es am laufen hast feststellen das die Performance nicht reicht.

die Base hingegen auf einer annähernd beliebigen alternativen x86 Hardware zum laufen zu bringen ob auf der nackten Hardware oder virtualisiert ist zumindest mit der aktuellen FW 1.7.88 möglich. (Wobei ich noch nicht testen konnte ob in meiner virtuellen Base die TimeSource so gut ist, das die Syncronisierung der Lautsprecher mit <5ms eingehalten wird.)

@alle virtualisierungs Interessierten.
Ich schreibe es während der Osterfeiertage zusammen.

mystream schrieb:

In der CuBox werkelt ein Prozessor mit ARM Architektur. In der Base einer aus der x86 Welt.

Das kam mir inzwischen auch...
Interessanter wäre in dem Zusammenhang übrigens den Connector als Host auf einer potentielleren HW zum laufen zu bringen, und so die Limitierung durch RAM und CPU zu umgehen. Damit könnte man die Base komplett einsparen. Allerdings läuft der wiederum zwar auf nem Marvell, IMO allerdings wiederum kein ARM

mystream schrieb:

Ich schreibe es während der Osterfeiertage zusammen.

Das ist schön, dann kann ich nach der NAB loslegen, Danke...

mystream schrieb:

Ich schreibe es während der Osterfeiertage zusammen.

Ich bin nach erfolglosen Versuchen auch sehr gespannt.
Wünsche ruhige Osterfeiertage

Dachte schon mit der 1.7.106 würde es nicht mehr gehen die Base zu virtualisieren. Raumfeld scheint irgend etwas geändert zu haben das zumindest mit meiner Konfiguration den HostRollenTransfer vom Speaker auf die Base instabil gemacht hat. Funktionierte mit der 1.7.88 völlig Problemlos in beide Richtungen beim 1ten Versuch. Mit der aktuellen FW braucht es mehrere Versuche bevor der Transfer durchgeführt wird. Im Fehlerfall kommt nur kurz die Meldung bzgl. des Kopierens der Favoriten, dann bricht er aber ab und der alte Host behält seine Rolle. War der Transfer dann aber nach einigen versuchen erfolgreich funktioniert es wie gehabt. Den Transfer initiere ich am Controller über Einstellungen->Netzwerk->Hostkonfiguration->HostkonfigurationÄndern. Bei Fehlfunktion stehen im Log einige crashes. Sieht etwas so aus wie eine Laufzeit Condition mit einem Timinig auf der Kippe.

Sollte das jemand mit der aktuellen Firmware und einer echten Base auch beobachten, bitte ich um Hinweis. Würde mich beruhigen wenn es nichts mit der "unechten" Hardware zu tun hätte.

Ansonsten bleibts bei Ostern mit der Doku.

mystream

mystream schrieb:

Raumfeld scheint irgend etwas geändert zu haben

Definitiv nicht. Bitte schalte mal das automatische reporting ein und probiere es nochmal. Wenn Du crashes hast, schick mir bitte die MAC-Adresse Deines Speakers und der VM-Ware per PM, dann kann ich im Crash-Reporter nachsehen, was da schief läuft.

mystream schrieb:

Ansonsten bleibts bei Ostern mit der Doku.

Da gibt es ja seit kurzem dieses hilfreiche Wiki: http://de.raumfeld.wikia.com/wiki/Raumfeld_Wiki

Hallo allerseits,

ich hätte auch Interesse daran, die Base als Software zu betreiben, sei es in ner virtuellen Maschine oder besser noch irgendwie direkt auf einem NAS. Mancheiner hat vielleicht sogar einen eigenen NAS-Server, worauf man so etwas betreiben könnte....

Grüße

mystream schrieb:

Ansonsten bleibts bei Ostern mit der Doku. mystream

Tja, Ostern ist schneller vorbei als einem lieb ist,
mir ging es auch so
Gibt es vielleicht noch ein paar wichtige Kurzhinweise
bevor ich mich mal dran mache?
Hat Thomas Raumfeld noch Infos durchgegeben ohne
die man es gar nicht erst versuchen braucht?

Gruß Uwe

Da hat man ja nicht mal Zeit das noch mal zu überprüfen.
Die Beschreibung ist verfasst. Wer Fehler findet möge sich melden.

Raumfeld Base goes Virtual

mystream

WOW!!! Das nenn ich mal Engagement! Danke!

mystream schrieb:

Da hat man ja nicht mal Zeit das noch mal zu überprüfen.

War nicht bös gemeint, ich dachte nur Du wärst Ostern nicht dazu gekommen.

Spitzen Erklärung!
Ich war da völlig auf dem Holzweg und hätte sicher ewig gebraucht.
Es hat genau so geklappt wie Du es erklärt hast.
Vielen Dank!

Ok, hab das mal probiert.
Also wenn er mir dann beim booten der VM brav lilo bringt aber danach sagt ich hab kein 3DNow dann nehme ich mal an ich hab was falsch gemacht?

Bin leider auf dem Gebiet nicht gerade gut bewandert. Hab ich den Kernel irgendwie falsch wo reingegeben?

EDIT: Habs nun auch geschafft. Hatte mich wohl ein bisschen im linux verworren...

EDIT: Ok jetzt aber ein Problem. Die virtuelle Base bekommt keine IP über DHCP
eth0 Device not found. Keine Ahnung ob das ok ist? br0 würd über DHCP eine IP suchen. kriegt aber nix.

Das mit br0 ist OK, Bridge für eth0

Vielleicht...
hast Du nicht
Netzwerkkarte vom Typ VMXNET3
bei der VM ausgewählt?
Netzwerkarte beim Start verbunden?
Ist ein Haken in den Einstellungen der Netzwerkkarte.

Sicher das ein DHCP für kabelgebundene
Geräte da ist?
Manche Router kann man so konfigurieren das zwar
WLAN-DHCP geht aber Kabel nicht.

Otze99 schrieb:

Das mit br0 ist OK, Bridge für eth0 Vielleicht... hast Du nicht Netzwerkkarte vom Typ VMXNET3 bei der VM ausgewählt? Netzwerkarte beim Start verbunden? Ist ein Haken in den Einstellungen der Netzwerkkarte. Sicher das ein DHCP für kabelgebundene Geräte da ist? Manche Router kann man so konfigurieren das zwar WLAN-DHCP geht aber Kabel nicht.

Also DHCP sollte da sein. Die "Original" Base hängt auch direkt mit kabel am Router und bezieht für sich die IP.
"Connect at Power on" ist aktiv.

Aber was anders ist als bei der Beschreibung, ist die VMware. Ich benutze nicht die VMware vSphere Hyperviso (ESXi) Hypervisor sondern die VMware Workstation 8. Hier gibts kein VMXNET3. Sondern "nur" VMNET3. Sieht wohl aus als ob es sich da wo spießt.

EDIT: Gehe ich richtig in der Annahme dass das VMXNET3 einfach einen Netzwerkadapter bridged?

ChriD schrieb:

Aber was anders ist als bei der Beschreibung, ist die VMware. Ich benutze nicht die VMware vSphere Hyperviso (ESXi) Hypervisor sondern die VMware Workstation 8. Hier gibts kein VMXNET3. Sondern "nur" VMNET3. Sieht wohl aus als ob es sich da wo spießt. EDIT: Gehe ich richtig in der Annahme dass das VMXNET3 einfach einen Netzwerkadapter bridged?

Laut Websuche gibt es Leute die den vmxnet3 unter VMware Workstation 8 verwenden. Schau doch mal explizit in der .vmx Datei nach ob da ein

ethernet0.virtualDev = "vmxnet3"

drin steht.

Weiterhin kannst du prüfen ob in der gebooteten VM in der /tmp/messages so was wie

Apr 14 10:14:44 RaumfeldMusicServer kern.info kernel: [ 4.401566] VMware vmxnet3 virtual NIC driver - version 1.1.18.0-k-NAPI
Apr 14 10:14:44 RaumfeldMusicServer kern.info kernel: [ 4.403416] # of Tx queues : 1, # of Rx queues : 1
Apr 14 10:14:44 RaumfeldMusicServer kern.info kernel: [ 4.403624] vmxnet3 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ 18
Apr 14 10:14:44 RaumfeldMusicServer kern.debug kernel: [ 4.403838] vmxnet3 0000:03:00.0: setting latency timer to 64
Apr 14 10:14:44 RaumfeldMusicServer kern.info kernel: [ 4.410515] (unregistered net_device): features: sg csum vlan jf tso tsoIPv6 lro highDMA
Apr 14 10:14:44 RaumfeldMusicServer kern.info kernel: [ 4.410784] Using INTx interrupt, #Rx queues: 1.
Apr 14 10:14:44 RaumfeldMusicServer kern.info kernel: [ 4.411167] eth0: NIC Link is Up 10000 Mbps

drin ist.

Und der Output von "lspci -k" müsste

00:07.1 Class 0101: 8086:7111 PIIX_IDE
02:00.0 Class 0c03: 15ad:0774 uhci_hcd
02:01.0 Class 0c03: 15ad:0770 ehci_hcd
03:00.0 Class 0200: 15ad:07b0 vmxnet3

enthalten.

Verwendest Du den Kernel von mir oder hast Du selbst einen gebaut ?

Was liefert ein ifconfig ?