[Silvan]

La gestione dell’audio da parte di più applicazioni avviene tramite il plugin dmix di alsa (vedi /etc/asound.conf). In questo momento è noto che amarok4 prende comunque l’uso esclusivo dell’audio, forse capita anche per dragon player. In ogni caso non ho ancora affrontato il problema ma è per me noto.

[Silvan]

Potete provare avviando da CD o da USB l’ultima snapshot in modo da verificare se anche così si verifica il problema?

[Silvan]

In openmamba 1.0 jack era abilitato di default, quindi puoi vederne un esempio funzionante. Successivamente l’ho disabilitato per diverse ragioni:

la prima è che con i nuovi kernel non è più possibile usare oss2jack per l’emulazione oss attraverso jack;

la seconda e più importante ragione (in quanto esistono metodi alternativi a oss2jack come aoss), è che il plugin flash e/o firefox non sono progettati per gestire la bassa latenza con il risultato di causare problemi a tutte le applicazioni che usano jack che sono collegate ad anello attraverso una forma cooperativa di threading. Finché un thread dell’anello non ha finito, non viene eseguito il successivo. Il risultato è una lunga serie di “xrun” che si vedono nel file di log (.xsession-errors) e l’audio che perde dei pezzi, nonché le applicazioni che vanno in crash.

Nella versione 1.1pre e devel di openmamba, jack si può abilitare usando qjackctl quando si intende utilizzare applicazioni per l’audio professionale (ad esempio audacity), garantendo così una maggiore resa del suono rispetto a prima in quanto le altre applicazioni come firefox non creano conflitti poiché sono escluse dall’uso dell’audio. Si potrebbe fare un layer di emulazione oss più adatto, ma, almeno qualche mese fa, nessuno l’aveva fatto, oss2jack non risultata più mantenuto e alcune altre distribuzioni si sono orientate ad usare pulseaudio, comunque non senza problemi mi sembra.

[Silvan]

Qual è la versione di openmamba in questione?

[Silvan]

Non ho capito bene dove sia il problema.

(prima segnalazione) Sei riuscito a far partire il sistema live, a fare l’installazione ma poi non si avvia il sistema al reboot?

(seconda segnalazione) Sei riuscito a far partire il sistema live, a far partire l’installazione ma questa non arriva alla fine?

[Silvan]

Se disponi di un chip NVIDIA il problema è già stato riportato e sembrerebbe essere collgato a quando scritto in questo forum:

http://forum.kde.org/opensuse-11-1-kde4-nvidia-no-kdm-x-t-22110.html

ovvero il nuovo kdm di KDE4 va in timeout a causa del caricamento in ritardo del driver NVIDIA.

Per verificare se questo è il problema, potete provare ad aggiungere la riga:

nvidia

nel file /etc/modules, riabilitare le estensioni composite in Xorg.conf e riavviare.

In questo modo il driver viene caricato prima dell’avvio di X e quindi KDM potrebbe non andare in timeout. Se questo risolve, posso pensare di fare una fix permanente per questo problema.

[Silvan]

Quale versione del livecd hai provato? Dovrebbe essere almeno al 1.1pre o la devel. Se si ferma alla fine puoi provare a partire senza ambiente grafico (aggiungi un “3” alla linea di comando di avvio del kernel).

[Silvan]

Il bug cui ti riferisci riguardava wireless assistant ed è stato automaticamente superato con l’introduzione di wicd che è risultato funzionante. Tu invece segnali problemi con quest’ultimo e questo richiede l’apertura di un problema, nuovo e differente.

[Silvan]

Fab: quello che hai scritto non mi torna utile per la risoluzione del problema, ovvero le interfacce wireless hanno normalmente Link encap:ether e non so come considerare l’informazione che in basso ci sia un bottone “disabilita l’interfaccia”. La risoluzione di questo problema seguirà i normali processi di sviluppo di openmamba, al momento sto considerando per altri motivi di investire nell’acquisto di un eeepc e nel caso sicuramente potrei valutare la situazione con questo hardware, sempre se si tratta di un problema dipendente dall’hardware. Quando ho avuto la possibilità di usare un eeepc, ovvero a seguito dell’acquisto da parte di clienti, ho verificato il corretto funzionamento del wireless. A questo punto non essendo questo un bug report ma una discussione del forum, non ricordo più quale versione di openmamba stai utilizzando e tutto il regresso e non ho la possibilità in termini di disponibilità temporale di rileggere tutti i messaggi ogni volta, quindi il meglio che puoi fare se desideri che questo problema sia risolto al più presto, nonché se vuoi dare un contributo alle altre persone che usano e useranno openmamba, è aprire una segnalazione su bugs.openmamba.org descrivendo _separatamente_ i sintomi del problema (necessario) e le tue ipotesi di soluzione (opzionale).

[Silvan]

mmm sulla stabile la cosa di sopra credo non funzioni, ma per capire proverei, qualunque sia la versione usata, a dare i seguenti comandi:

sudo ifconfig wlan0 down

sudo ifconfig wlan0 up

per vedere se dopo

iwlist wlan0 scan

funziona. ‘wlan0’ è da sostituire con il nome dell’interfaccia wireless disponibile.

[Silvan]

Se usate la versione stabile per l’uso con wicd provate a dare:

sudo chkconfig –del network

e a riavviare.

Se la situazione peggiora tornate indietro con:

sudo chkconfig –add network

[Silvan]

Se hai solo un dispositivo wireless prova prima con wlan0, poi con ra0 e poi con ath0.

[Silvan]

Mi è capitato di verificare che python-dbus non è una dipendenza richiesta, ma è richiesto pygtk, quindi puoi provare con:

sudo apt-get install pygtk

[Silvan]

Assicuratevi che nelle impostazioni di wicd (Preferenze -> Impostazioni generali) vi sia il nome dell’interfaccia wireless configurato dove dice “Interfaccia wireless:”. Il nome dell’interfaccia è a seconda dei casi qualcosa come wlan0, ra0, ath0.

[Silvan]

Probabilmente manca come dipendenza il modulo python-dbus che puoi installare con

sudo apt-get install python-dbus

[Autore]

Articoli