XMMS(soundkarte?) macht sporadisch Fehler

P

Pagai

Active Member
Hallöchen!

Folgendes Problem, ich benutze FreeBSD nur Testweise um mich ein wenig in Betriebssysteme reinzufuddeln und um von Windows weg zu kommen.

Dazu gehört natürlich auch die ganze Multimedia-Funktionalität. Sprich, MP3s-hören als Grundlage.

Ich hab mir XMMS runtergeladen, mit ein paar Plugins, Skins und so weiter um zu wissen wie was so geht.

Das funktioniert auch recht gut. Nur ab und an, nach 1-XXXX Liedern kommt ein Fehlergeräusch (wo man diese hinweistöne ausstellen kann würde mich auch mal interessieren) und XMMS hört auf zu spielen, bzw lädt das nächste Lied nicht.
Dies geschiet unmittelbar nachdem ein Lied abgeschlossen wurde. Demnach geh ich davon aus, dass der die Soundkarte deinitialisiert und anschliessen wieder initialisiert, oder was ähnliches tut. Dies nicht funzt und er die Fehlermeldung ausgibt.

in der Console bekomme ich die Meldung :

** WARNING **; oss_open(): Failed to open audio device (/dev/dsp): Device busy

Ich schliesse mal daraus, dass das Device dsp (ich dachte die soundkarte is irgnedwas mit pcm oder so ?!) nicht gleichzeitig 2 sounds auf einmal abspielen kann, bzw von 2 Anwendungen gleichzeitig genutzt werden kann.
Dies ist eigentlich auch kein Problem, aber es ist doch nur XMMS auf welches darauf zugreift.

Zusätzlich kommt auch im KDE noch ein Fensterchen, welches mir einige (3) Vorschläge macht was denn nicht stimmen könnte.

Ich warte dann ca. 30sek-1min. klicke in der Playlist nen Lied an und es funzt wieder.

Total komisch.

ist kein tragischer Fehler, nervt nur ein wenig. Gerade wenn man mal chillen will und dauernd aufstehen muss um daswieder zum spielen zu bewegen.

Danke im Vorraus
Grüße Pagai

PS : bitte kein Admin-Deutsch. Bin noch Newb im BSD-bereich.
 
Ich nehme mal an, du verwendest di oss Treiber (aufgrund der Fehlermeldung).

Wenn dem so ist, schau mal nach, wie deine Devices angelegt wurden, in der Konsole mit:

Code: 
bash-2.05b$ ./ossinfo
Version info: OSS/FreeBSD 3.99.2b (0x00040000)

Number of audio devices:        10
Number of MIDI devices:         1
Number of mixer devices:        2

MIDI devices (/dev/midi*)
00: AudioPCI97 (MIDI port 0 of card 0)
Mixer devices (/dev/mixer*)
 0: AC97 Mixer (STAC9721) (Mixer 0 of card 0)
 1: Virtual Mixer (Mixer 0 of card 1)
Audio devices (/dev/dsp*)
 0: Ensoniq AudioPCI97 (ES1371) (rev 8) (audio port 0 of card 0)
 1: Ensoniq AudioPCI97 (ES1371) (playback only) (audio port 1 of card 0)
 2: OSS Virtual Mixer v2.5 Playback CH #0 (audio port 0 of card 1)
 3: OSS Virtual Mixer v2.5 Playback CH #1 (audio port 1 of card 1)
 4: OSS Virtual Mixer v2.5 Playback CH #2 (audio port 2 of card 1)
 5: OSS Virtual Mixer v2.5 Playback CH #3 (audio port 3 of card 1)
 6: OSS Virtual Mixer v2.5 Playback CH #4 (audio port 4 of card 1)
 7: OSS Virtual Mixer v2.5 Playback CH #5 (audio port 5 of card 1)
 8: OSS Virtual Mixer v2.5 Playback CH #6 (audio port 6 of card 1)
 9: OSS Virtual Mixer v2.5 Playback CH #7 (audio port 7 of card 1)

Mit der oben stehenden Ausgabe musste ich im XMMS unter Preferences beim output Device also /dev/dsp0 eintragen.

Außerdem musst du sicherstellen, dass kein weiterer soundtreiber geladen wird/ist. Hast du sonst noch irgendwelche soundtreiber geladen, im Kernel oder in der loader.conf?
 
Ich schliesse mal daraus, dass das Device dsp (ich dachte die soundkarte is irgnedwas mit pcm oder so ?!) nicht gleichzeitig 2 sounds auf einmal abspielen kann, bzw von 2 Anwendungen gleichzeitig genutzt werden kann.
Zum Vergrößern anklicken....
für solche sachen brauchst du einen sound daemon, wie esound z.B. meiner meinung nach sind diese dinger aber grauenhaft. ich würde dir empfehlen z.b. eine creative soundkarte zu kaufen, dann hast du dieses prob nicht mehr und kannst alle progs die töne von sich geben wollen nach /dev/dsp zeigen lassen. schont die nerven und den prozessor :)
 
Hm, habe ein ganz ähnliches Problem, nur, ./ossinfo brachte gar keine Resultate, weil scheinbat nicht vorhanden.
Habe die gleiche Soundkarte wie Du, Martin. Über snd_es137x_load="YES" in der /boot/loaeder.conf wird das entspr. Modul auch gut geladen. Braucht man da noch sound_load="YES"?
Unter anderen Anwendungen geht es auch prima, nur xmms spuckt in die Suppe und kratzt erbärmlich, wenn ich *.mp3- oder *.ogg-Files abspiele. Habe über Google erfahren, daß noch mehr Leute das Problem haben, insbesondere bei Multiprozessorsystemen. Das Phänomen ist ganz ähnlich, ein paar Minuten saubere Ausgabe, dann wieder Störgeräusche. Zudem will xmms scheinbar ganz allein residieren, wenn ich davor ein anderes Programm geladen hatte, findet er plötzlich keinen Soundtreiber mehr. --- Rätsel über Rätsel.
Hat jemand eine Idee, die wirklich hilft?
Hier war leider auch kein Lösungsansatz: http://lists.freebsd.org/pipermail/freebsd-questions/2005-January/072914.html
Fahre FreeBSD 5.4 RC1 auf Abit Dual Pentium III, SoundBlaster 128 PCI .
 
Zuletzt bearbeitet:
Hallöchen!

Danke erstmal für alle Antworten !

Eine Creative-Soundkarte kaufen könnte ich ... aber... ich kann die schlecht in meinen Laptop einbauen x)))

Ich glaube ich werde mich damit abfinden müssen.
unter VLC hab ich das Problem nicht. hmmm...

ok...danke !
 
pagai: ich bin zwar kein kde-user, aber hast du schonmal probiert einfach die hinweistoene auszuschalten?
sonst mach nochmal folgendes: logge dich im failsafe-modus ein (nach dem passwort nicht ENTER, sondern F1 druecken).
du kriegst dann nur ein kleines xterm, gib in dem mal ein:

Code: 
% twm &
% xmms &

und guck nach, ob die fehler da auch auftreten. wenn ja----> problem mit deiner soundkarte. sonst-> problem mit kde.
 
hmkay...werd ich mal probieren...und das ergebnis hierhin posten...
hehe...die idee mit den hinweistönen ist mir auch schon gekommen aber habs noch nich probiert x)))

danke erstmal !
 
OK...es hat funktioniert. ich hab einfach die KDE-sounds abgestellt und schon keine fehler mehr... wunderbar...danke für den tip !!
gruß
Pagai
 
Das Problem ist, dass xmms /dev/dsp0 oeffnen will, und KDE (genauer artsd) auch ab und an /dev/dsp0 fuers schreiben oeffnen will -> Schlecht.

Moegliche Loesung: Virtuelle Kanaele

echo "hw.snd.pcm0.vchans=4" >> /etc/sysctl.conf

und dann in xmms /dev/dsp0.3 einstellen, fuer den artsd fest /dev/dsp0.2 einstellen. Fuer mplayer/xine kannst du dann noch /dev/dsp0.1 fest vorgeben. Alles andere versucht /dev/dsp0, welches ein Link nach dsp0.0 ist.

Der emu10k1-Chip hat 4 Kanaele in Hardware, bei anderen muss das in Software zusammengemixt werden. Es koennte also zu Problemen kommen. Mir sind aber noch nie welche aufgefallen.
 
i18n schrieb:
Hm, habe ein ganz ähnliches Problem, nur, ./ossinfo brachte gar keine Resultate, weil scheinbat nicht vorhanden.
Habe die gleiche Soundkarte wie Du, Martin. Über snd_es137x_load="YES" in der /boot/loaeder.conf wird das entspr. Modul auch gut geladen. Braucht man da noch sound_load="YES"?
Unter anderen Anwendungen geht es auch prima, nur xmms spuckt in die Suppe und kratzt erbärmlich, wenn ich *.mp3- oder *.ogg-Files abspiele. Habe über Google erfahren, daß noch mehr Leute das Problem haben, insbesondere bei Multiprozessorsystemen. Das Phänomen ist ganz ähnlich, ein paar Minuten saubere Ausgabe, dann wieder Störgeräusche. Zudem will xmms scheinbar ganz allein residieren, wenn ich davor ein anderes Programm geladen hatte, findet er plötzlich keinen Soundtreiber mehr. --- Rätsel über Rätsel.
Hat jemand eine Idee, die wirklich hilft?
Hier war leider auch kein Lösungsansatz: http://lists.freebsd.org/pipermail/freebsd-questions/2005-January/072914.html
Fahre FreeBSD 5.4 RC1 auf Abit Dual Pentium III, SoundBlaster 128 PCI .
Zum Vergrößern anklicken....

Gibt es denn schon eine Lösung für dieses Problem???

Weil ich stelle das bei mir nun auch gerade fest und muss sagen: ES NERVT TOTAL!

> cat /dev/sndstat
FreeBSD Audio Driver (newpcm)
Installed devices:
pcm0: <VIA VT8235> at io 0xe100 irq 5 kld snd_via8233 (5p/1r/0v channels duplex default)
 
Pagais Anfrage ist schon gelöst, aber die meine nicht.
Ich habe gar kein kde, aber das Problem besteht immer noch, was meint, dieses nervende Piepsen ab und zu.
 
Hast du den Vorschlag von Mr. Fixit mit den vchans aufgegriffen? Ich habe hw.snd.maxautovchans="8" in meiner /boot/loader.conf und damit gibt es dann keine Probleme mehr. Ich empfehle noch den Port xmms-crossfade zu installieren, der installiert das crossfade-plugin mit dem man xmms gapless-playback beibringen kann.
 
Hm, dankeschön. Scheint erst mal so zu funktionieren. Ich teste es morgen noch mal ausgiebig, aber bislang hört es sich gut an. Fein ist auch an dem von Dir vorgeschlagenen Plugin, daß man die Sache über Volnorm laufen lassen kann -- endlich die angemessenen Lautstärke!
 
Zum ursprünglichen Problem: Wenn man mit nicht-KDE-Anwendungen (XMMS, Xine, MPlayer usw.) unter KDE Sounds ausgeben will, die Soundkarte aber nur einen Ausgabekanal hat, muß man eine der folgenden Möglichkeiten ergreifen:
  • Das doofe KDE-Soundsystem im KDE-Kontrollzentrum deaktivieren. Schnellste Lösung, habe ich auch so gemacht. Dann bekommt man halt gar keinen Sound mehr von KDE-Anwendungen, brauch ich auch nicht. Außerdem spart man die CPU-Zeit, die das KDE-Soundsystem zum Zusammenmischen so überlicherweise verbrät.
  • vchains erhöhen und in jeder Anwendung manuell einen bestimmten virtuellen Kanal zur Ausgabe einstellen (siehe Post von MrFixit). Ist mir aber zu umständlich.
  • Kauf einer Soundkarte mit mehreren Kanälen (z.B. Creative SoundBlaster 5.1 oder Audigy). Braucht man natürlich einen PCI-Slot, hat man aber nicht überall.
  • Die Anwendung (XMMS, MPlayer usw.) über artsdsp mit dem artsd verkuppeln. Ob das reibungslos funktioniert, hängt vom Einzelfall ab.
  • Für XMMS und Xine (vielleicht auch für andere) gibt es arts-Ausgabe-Plugins im Portstree. Das ist IMO die sauberste Lösung, wenn man auch weiterhin KDE-Sounds hören will.
Dagegen besteht das Problem von i18n wohl darin, daß irgendeine Anwendung einen Warnton ausgeben möchte und warten muß, bis die Soundkarte zwischendrin "frei" wird. Die SoundBlaster 128 hat jedenfalls nur einen Kanal.
 
0815Chaot schrieb:
  • vchains erhöhen und in jeder Anwendung manuell einen bestimmten virtuellen Kanal zur Ausgabe einstellen (siehe Post von MrFixit). Ist mir aber zu umständlich.
Zum Vergrößern anklicken....

Ich muss mich korrigieren, dass ganze funktioniert auch ohne manuelle Zuweisung (so ist es auch eigentlich gedacht). Es hat nur irgendwie vor langer Zeit bei mir nicht funktioniert, deshalb bin ich auf die manuelle Methode umgestiegen.

D.h. artsd/xmms/Co laufen ohne weitere Zicken, sobald man die ein/zwei sysctls hochsetzt. (Jedenfalls _sollte_ es so gehen :D )
 
Hmm, kann natürlich sein, daß das Prinzip der vchains neuerdings von den Anwendungen aktiv verwendet wird. Heißt also, XMMS (als Beispiel) guckt nach, welche dsp-Devices im System vorhanden sind. Dann versucht es zuerst /dev/dsp0.0 zu öffnen. Device busy? Dann wird eben /dev/dsp0.1 versucht. Erst wenn alle dsp-Devices auf dem System nicht geöffnet werden können, zeigt XMMS die Fehlermeldung an, daß die Soundkarte nicht geöffnet werden kann.

Vorstellen könnte ich mir auch, daß der Kernel eine Anforderung an /dev/dsp0.0 einfach auf /dev/dsp0.1 umbiegt, sollte /dev/dsp0.0 schon belegt sein. Das halte ich aber nicht für gut, weil die Anwendung IMO schon wissen sollte, auf welchem Device sie tatsächlich arbeitet.

Jetzt könnte man natürlich im Source nachgucken, aber da bin ich gerade zu faul dafür. Da man das auf Anwendungsebene aber schnell und einfach lösen kann (einfach den Rückgabewert auswerten), denke ich, daß man das so gelöst hat.
 
Ey Leute, warum nehmt Ihr nicht einfach Gnome? Da habt Ihr dieses Problem nicht, auch nicht, wenn Ihr gnome sound events aktiviert, falls Ihr sowas braucht.
Für meinen Teil finde ich es interessant, wieder auf einen guten Grund gestoßen zu sein, warum man KDE nicht nehmen sollte...
 
ROTFL. Wenn das ein Grund sein soll, GNOME zu verwenden, dann ist es um GNOME aber ziemlich schlecht bestellt. GNOME nimmt man, wenn man Bugs im Überfluß haben will, aber kein Windows installieren möchte.
 
0815Chaot schrieb:
Vorstellen könnte ich mir auch, daß der Kernel eine Anforderung an /dev/dsp0.0 einfach auf /dev/dsp0.1 umbiegt, sollte /dev/dsp0.0 schon belegt sein. Das halte ich aber nicht für gut, weil die Anwendung IMO schon wissen sollte, auf welchem Device sie tatsächlich arbeitet.
Zum Vergrößern anklicken....
So aehnlich funktioniert das. Nur wird XMMS nie versuchen dsp0.0 zu oeffnen (es sein denn, man stellt das ein), sondern es wird immer nur /dev/dsp geoeffnet. Der Kernel sorgt dann dafuer, dass ein freier vchan zur Verfuegung gestellt wird. Greift man direkt auf dsp0.0 zu, dann muss 0.0 auch wirklich frei sein. Deshalb nehme ich inzwischen Abstand davon, den Kanal fest zuzuweisen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben