PDA

Visualizza versione completa : script sh/bash - kdialog va in conflitto con wine



Andy86
28-02-14, 15: 27
:bai

Volevo mettermi un promo per accendere il pad quando avvio pes, altrimenti non lo vede (o meglio, lo vede come generico ed escono i tasti sbagliati) e devo riavviare il gioco; però facendo così:


Only registered members can view code.

esce l'audio sballato e non riesco a capire perché.
se commento kdialog funziona bene. :boh

Ho provato anche a mettere uno sleep prima di avviare il gioco, ma non è cambiato nulla. :boh

ps: avevo già notato che wine s'impossessa del device audio e non permette di usarlo nemmeno per altre istanze di wine oltreché per altri software. Possibile che kdialog faccia lo stesso all'inverso? :boh

pierino_89
01-03-14, 03: 29
Ad occhio, non c'è motivo razionale per cui non debba funzionare. Quindi di propongo un metodo più logico di affrontare il problema: fai un test sull'esistenza del dispositivo e, se non è presente, mostra il messaggio di errore con kdialog invece di avviare il gioco :eye

Andy86
01-03-14, 12: 33
:bai

Solo che il ricevitore wireless è sempre collegato, quindi /dev/input/js0 c'è sempre.

Probabilmente il problema è dovuto al fatto che il pad ha uno switch per scegliere se essere xinput o directinput, quindi finché non lo accendo il ricevitore non sa dov'è lo switch e rimane auto su xinput:


Only registered members can view code.

dopo essere stato acceso:


Only registered members can view code.

Per applicare la tua soluzione dovrei quindi riuscire a processare l'output di lsusb... dopo ci penso, ma con tutti quegli spazi la vedo dura. :shock

pierino_89
01-03-14, 12: 46
In realtà a prima vista basta testare se in tutto l'output compaia "rumblepad" ;)

Andy86
01-03-14, 13: 14
:thx, non avevo pensato al buon vecchio grep.

fatto così:


Only registered members can view code.

Ad un primo test pare che funzioni.

pierino_89
01-03-14, 14: 05
Io preferisco la buona vecchia sintassi:

Only registered members can view code.
ma di fatto è la stessa cosa. Ti consiglio comunque di mettere la variabile fra virgolette nel test, l'output di lsusb contiene spazi e può darti problemi.

Andy86
01-03-14, 15: 03
Io invece la vecchia sintassi la odio, perché mi devo sempre ricordare il significato delle lettere, preferisco la sintassi standard come in java e in c/c++. :tong2

Andy86
06-03-14, 19: 40
:bai

Comunque mi piacerebbe proprio sapere perché quando kdialog e wine vengono lanciati nella stessa esecuzione dello script bash non funziona l'audio. Non capisco se il problema è bash o cosa, perché se lancio kdialog da terminale e poi wine (anche senza chiudere kdialog) funziona bene, invece modificando lo script in modo da non doverlo lanciare due volte:


Only registered members can view code.

esce ancora il problema dell'audio. :wall

pierino_89
06-03-14, 21: 10
È una domanda molto ricca di variabili. Kdialog quando fa la finestra sicuramente emette un suono tramite il demone di kde, che deve appoggiarsi ad alsa o pulseaudio. Allo stesso modo anche wine deve appoggiarsi ad alsa o pulseaudio. Il problema può avvenire nel caso in cui kde sfrutti pulseaudio e wine usi alsa, perché pulseaudio prende possesso del device in modo esclusivo.
Allo stesso modo quando lanci un programma che si appoggia direttamente ad alsa, pulseaudio non è in grado di riprodurre nulla.
Puoi facilmente verificarlo lanciando un programma tramite wine e, mentre suona, lanci amarok o fai il test del sonoro dal pannello di controllo :oo2

Riguardo al motivo per cui dopo aver eseguito il suono di notifica pulse non rilasci il dispositivo (ma solo se il comando è stato lanciato all'interno di uno script), non ne ho proprio idea.
Io con crossover (che non supportava pulseaudio fino a qualche versione fa) usavo il comando "aoss", che emula il sistema sonoro OSS (antico concorrente di alsa) facendo uscire il suono risultante direttamente su alsa, ma ha anche un plugin per pulseaudio. Implica un chilo di passaggi in più (applicazione -> aoss -> OSS -> pulseaudio -> alsa -> suono effettivo), ma almeno funziona :ghgh

(comunque personalmente avrei messo un "exit 1" dopo kdialog e lasciato perdere :lol:)

Andy86
06-03-14, 21: 30
Se dovevo mettere exit allora non stavo a fare il ciclo while.
Era per non dover riaprire il programma in caso di errore.

Tra l'altro pulseaudio non ricordo perché lo avevo rimesso... magari lo rilevo e lascio solo alsa.



usavo il comando "aoss"


In winetricks c'è la possibilità di selezionare oss (senza A) come driver audio, ma poi non si può più selezionare il device e non si sente nulla. :boh

Il comando aoss c'è, ma ottiene come risultato quello di accellerare il gioco (come venissero riprodotti più fps di quelli effettivi) e il problema audio permane.


Puoi facilmente verificarlo lanciando un programma tramite wine e, mentre suona, lanci amarok o fai il test del sonoro dal pannello di controllo :oo2

Si, avevo avuto occasione di accorgermene, fa la stessa cosa anche se lancio mplayer o vlc. :sisi


Riguardo al motivo per cui dopo aver eseguito il suono di notifica pulse non rilasci il dispositivo (ma solo se il comando è stato lanciato all'interno di uno script)

Quindi è quello il problema?
Sicuro che non c'è qualche comando per forzare il rilascio, o per dire a kdialog di non usare il suono per quella specifica sessione?

pierino_89
06-03-14, 21: 54
Tra l'altro pulseaudio non ricordo perché lo avevo rimesso... magari lo rilevo e lascio solo alsa.

Sempre se ci riesci ancora... Ormai mezzo mondo lo avrà per dipendenza :ghgh



In winetricks c'è la possibilità di selezionare oss (senza A) come driver audio, ma poi non si può più selezionare il device e non si sente nulla. :boh
E per forza, se avessi i moduli e le librerie di OSS non potresti usare alsa e non ci sarebbe bisogno di aoss :tong2



Il comando aoss c'è, ma ottiene come risultato quello di accelerare il gioco (come venissero riprodotti più fps di quelli effettivi) e il problema audio permane.
Questo è strano forte, ma se non risolve il problema è inutile pensarci...


Si, avevo avuto occasione di accorgermene, fa la stessa cosa anche se lancio mplayer o vlc. :sisi
Eh ma che noia, avevo sentito dire che ormai anche wine era provvisto del suo bel plugin per pulseaudio. Non puoi cercare di installarglielo? Ti creerà sempre casini se pretende di passare su alsa.



Quindi è quello il problema?
Il vero problema è quello sopra. :ghgh



Sicuro che non c'è qualche comando per forzare il rilascio, o per dire a kdialog di non usare il suono per quella specifica sessione?
Credo ci sia nei parametri un tempo di standby di pulseaudio, ma non pare correlato visto che non dovrebbe cambiare nulla dentro e fuori dallo script in termini temporali. Puoi provare a terminare pulseaudio e rilanciarlo dopo la chiusura, ma penso che molti programmi se la prenderebbero a male. Altro non so, guardati il man di pacmd :eye

Andy86
06-03-14, 22: 46
:bai

Ho scoperto che kdialog --progressbar non lancia il segnale audio (e non devo neanche premere ok per continuare), quindi per ora ho risolto così:


Only registered members can view code.

(ho dovuto sostituire le doppie tonde con le doppie quadre perché sputava fuori errori inesistenti)
Finché non salta fuori l'audio anche con progressbar.



Eh ma che noia, avevo sentito dire che ormai anche wine era provvisto del suo bel plugin per pulseaudio. Non puoi cercare di installarglielo? Ti creerà sempre casini se pretende di passare su alsa.


Se riesco a capire come si fa. Da winetricks c'è "alsa", "oss", "mac coreaudio" e "nessuno", solo il primo funziona, con gli altri non si può nemmeno selezionare il device.

Qui -> WineAndPulseaudio - The Official Wine Wiki (http://wiki.winehq.org/WineAndPulseaudio) -> dice che bisogna proprio farlo passare direttamente da alsa per farli coesistere, oppure impedire a pulseaudio di catturare il device. Secondo te qual'è la strada migliore delle due?

Andy86
09-03-14, 18: 39
Qui -> WineAndPulseaudio - The Official Wine Wiki (http://wiki.winehq.org/WineAndPulseaudio) -> dice che bisogna proprio farlo passare direttamente da alsa per farli coesistere, oppure impedire a pulseaudio di catturare il device. Secondo te qual'è la strada migliore delle due?

Preferisci non esprimerti? :ghgh

pierino_89
09-03-14, 18: 47
Non sono due strade, sono due passaggi da fare in ordine :ghgh

Andy86
09-03-14, 19: 14
:ops: maledetto inglese. :wall

Comunque io ~/.pulse e ~/.asound.rc non ce li ho, però ho /etc/asound.conf che non so se è la stessa cosa e /etc/pulse/.
Dici che se li creo li vede, o meglio editare quelli di sistema?

pierino_89
09-03-14, 19: 29
.asoundrc va creato a mano, e per quando riguarda l'altro dice:

Only registered members can view code.
[/FONT][/COLOR]:ghgh

Andy86
04-04-14, 21: 20
:bai

Senti una cosa: che pulseaudio se ne vada in quel posto.

Disinstallandolo con -dd per ignorare le dipendenze si risolvono tutti i problemi e funziona ancora tutto senza dover smanettare con le configurazioni, e soprattutto funziona "monkey island SE collection" (:gogo) che con pulseaudio non andava, e stavo quasi smontando wine per capire il motivo del crash... invece era colpa di pulseaudio. :furious

Unico problema potrebbe essere l'uscita hdmi della scheda video che non ci posso regolare il volume, ma ci penserò a tempo debito... per ora non mi serve. :tong2

Ah, non ho capito se metterlo in pacman.conf come ignore-pkg basta per evitare la resintallazione automatica. :m: Va be', vedremo.

Andy86
31-05-14, 15: 05
:bai

Versione 2.0 dello script


Only registered members can view code.

Lo so, lo so che ho esagerato. :bgg2

Andy86
01-06-14, 22: 25
Versione 2.1 (visto che la 2.0 l'ho rilasciata buggata. :ehmm)


Only registered members can view code.

Andy86
17-01-16, 12: 23
Scusate l'up.

Rilascio la versione 3.0, così faccio anche un backup.


Only registered members can view code.

Andy86
18-01-16, 19: 12
Minipatch - v [-]3.1[/-] [-]3.2[/-] 3.3 (e dalli con 'sti bug)


Only registered members can view code.