2012-01-09 11 views
6

Sto realizzando un gioco musicale e quando l'utente preme una nota produrrà un suono. Il suono naturalmente ha bisogno di suonare immediatamente quando l'utente preme, in modo che possano dire se sono in tempo con la musica. Tuttavia, sembra che il suono sia in ritardo, specialmente quando le note premute diventano più veloci.Cocos Denshion: Riproduci effetti sonori in sincronia con la musica

Il file di sottofondo .m4a viene riprodotto con AVAudioPlayer. Ho scelto di usarlo su Cocos Denshion poiché ho accesso alla proprietà currentTime. Potrei sbagliarmi, ma non penso di poter accedere a questo con CocosDenshion.

Ho creato un file wav che è estremamente breve (meno di un secondo). Ho precarico il mio effetto sonoro sulla init:

[[SimpleAudioEngine sharedEngine] preloadEffect:@"Assist.wav"]; 

poi a giocare l'effetto sonoro, in CCTouchesBegan io chiamo:

[[SimpleAudioEngine sharedEngine] playEffect:@"Assist.wav"]; 

Dopo di che si chiama il mio codice per determinare gli utenti di temporizzazione e assegna punti. Qualche idea sul perché potrebbe essere in ritardo o un modo migliore per riprodurre effetti sonori nel tempo con la musica?

EDIT: Ive ha provato alcune cose recentemente senza risultati. Per prima cosa ho provato a riprodurre i suoni automaticamente quando sono arrivati ​​al momento giusto nella canzone. Ho ancora avuto il ritardo, quindi non penso che gli eventi tattili siano lenti. Ho anche provato 3 diverse librerie di suoni.

Tuttavia, quando ho eseguito il simulatore, sembrava non essere lento. Qualcuno ha un'idea? Im incapacità ed è una caratteristica importante che non posso davvero fare ...

+0

prega di fornire informazioni su quali dispositivi sono in esecuzione, e strumenti X-Code informazioni sul carico della CPU e del carico gpu, e anche un'idea di quanti suoni allo stesso tempo stanno giocando, e in quale formato è la vostra musica di sottofondo (supponendo che ce ne sia uno). –

risposta

1

si dovrebbe evitare questo codice: - [[SimpleAudioEngine sharedEngine] preloadEffect: @ "Assist.wav"];

con l'inizio della applicazione si dovrebbe caricare il SimpleAudioEngine quadro scrivendo questo codice: -

// SimpleAudioEngine * palySound; creato oggetto nel file .h. palySound = [SimpleAudioEngine sharedEngine];

e ogni volta che si desidera riprodurre suoni è possibile scrivere: [palySound playEffect: @ "Assist.wav"];

+0

Grazie per la risposta. Ho provato questo, ma non sembra fare nulla di diverso. Il suono è ancora in ritardo. – Arbel

+0

Hai caricato SimpleAudioEngine in appdelegate in didFinishLaunchingWithOptions ... –

+0

Sì, non sembrava fare la differenza. Forse gli eventi tattili sono lenti? – Arbel

0

Non sono sicuro di quello che stai facendo nel tuo SoundEngine, ma nella mia esperienza personale, il modo migliore per non ottenere lag per riprodurre un suono è assegnare uno AVAudioPlayer per ogni file audio (a meno che non si voglia iniziare a fare scherzi in giro con AudioQueues).

Qui è un esempio:

Supponiamo che avete un AVAudioPlayer *assistPlayer; nel vostro controller della vista corrente.

Nel vostro viewDidLoad inizializzarla con il suono:

NSURL *wavURL = [[NSBundle mainBundle] URLForResource:@"Assist" withExtension:@"wav"]; 
assistPlayer = [[AVAudioPlayer alloc] initWithContentsOfURL:wavURL error:nil]; 

Poi, nel vostro IBAction in cui si desidera riprodurre il file, basta fare:

[assistPlayer play]; 

Non dovrebbe avere alcun ritardo .

+0

Provato ma non sembrava fare la differenza. In realtà ha avuto meno prestazioni. Denshion è un involucro piuttosto sottile per openAL. – Arbel

+0

Qual'è la frequenza di campionamento e la profondità di bit del tuo file wav? Hai provato a ricampionarlo e usarlo solo a 16 bit? –

0

Hai provato Finch? Sostiene di riprodurre suoni con bassa latenza, ed è anche solo un involucro attorno a OpenAL.

Oltre a questo, sto davvero non sperimentato con OpenAL, ma posso pensare a due possibili ragioni per il vostro ritardo:

  1. il thread principale è troppo occupato - Prova a scaricare il lavoro da esso per altri Filetti .

  2. Forse OpenAL è definito con un buffer troppo grande, quindi la pipeline carica l'intero suono nel buffer (o una grande parte di esso), e solo successivamente inizia la riproduzione.

+0

Sì, ho provato Finch, ma ho avuto gli stessi risultati di Denshion. Sono stato anche in grado di replicare questo in un progetto di esempio molto semplice https://github.com/so3arbelnox/soundtest – Arbel

Problemi correlati