×

Discussion Board

Results 1 to 8 of 8
  1. #1
    Registered User
    Join Date
    Mar 2004
    Posts
    12

    CMdaAudioInputStream & CMdaAudioOutputStream problem

    Dear Experts,

    I have implemented Audio Recorder and Audio Player classes derived from CMdaAudioInputStream and CMdaAudioOutputStream classes.
    The application receives some audio over socket that gets played by the Player.
    When I start recording, I make sure the Player is stopped and when I stop recording, I make sure the Recorder is stopped.
    Till here it works properly, meaning I get the proper callbacks. Now when I receive some audio and try to open the player, the player remains in EOpening state and MaoscOpenComplete(TInt aError) never gets called. What should be the problem?

    This application works properly on Nokia 3650 & 6600 device, but it simply doesn't work on Nokia 6620 and the new 6630 device.

    I'm fully aware of the fact that full-duplex audio is not possible at least on Nokia Series 60 devices. But if I'm not wrong this
    operation would be half-duplex. So why does it not work only on the new 6620 & 6630 phones?

    Does anyone have any clue?

    thanks a lot,
    Vikas

  2. #2
    Super Contributor
    Join Date
    Mar 2004
    Location
    Czech Republic
    Posts
    2,037
    Hi,

    it should work, at least my application works, I use 8.0a FP2 SDK. But as I understand you port solution from symbian 6.1 to 8.0a. Did you rebuild it with proper SDK? Probably some changes in the code are necessary, otherwise I dont know. But I could totally be wrong.
    Bye
    STeN

  3. #3
    Registered User
    Join Date
    Mar 2004
    Posts
    12
    Yes, I did compile with the latest SDK (S60_2nd_FP2) for 6630, but it doesnt work.

    Vikas

  4. #4
    Registered User
    Join Date
    Mar 2004
    Posts
    12
    Even the "Audio Streaming Example", I had downloaded from www.forum.nokia.com, doesn't work properly,
    Since this is an example from Nokia, it is less likely to have any bugs, etc.
    Simply compile, install it on a 6620 or 6630 phone and follow these steps:
    1. Choose "Record" from the menu. It display "Recording..." on the console and records 2 seconds (11200bytes * 3) worth data in iStreamBuffer.
    2. Select "Stop" from the menu. This will stop the Recorder and display "Recording stopped!". So now ou have 2 seconds worth recorded audio in iStreamBuffer.
    3. Select "Play" from the menu. This starts the Player and it should display "Playing". But it doesn't, because this display code is inside MaoscOpenComplete() and it never gets called.

    On the other hand, if you select "Play" instead of "Record" when the application starts, it plays garbage because iStreamBuffer has random data. From here if you repeat the above steps, you'd realize the problem.

    thanks,
    Vikas

  5. #5
    Super Contributor
    Join Date
    Mar 2004
    Location
    Czech Republic
    Posts
    2,037
    Hi,

    I used this example far ago, so I am sure it works. But now I download it once more from
    http://www.forum.nokia.com/main/1,65...l&fileID=4196.
    I build it, test it and it works wihtout problems...
    Try also SDK example
    ..\8.0a\S60_2nd_FP2\Examples\multimedia\audioclientex
    I really dont know where is your problem... I put piece of my code I used to start playing...

    // -----------------------------------------------------------
    TInt Play( const TFileName aFileName )
    {
    if ( ( iIState == EUninitialized ) &&
    ( iOState == EUninitialized ) )
    {
    // reinitialize output stream
    delete iOutputStream;
    TRAPD( error, { iOutputStream = CMdaAudioOutputStream::NewL( *this ); } );
    if ( error != KErrNone )
    return KErrUnknown;

    if ( iAmrFile ) delete iAmrFile;

    // load amr file into buffer
    if ( !IsValidAmrFile( aFileName ) )
    return KErrInvalidAmrFile;

    if ( ( iAmrFile = LoadFromFile( aFileName ) ) == NULL )
    return KErrNoMemory;

    // initalize variables
    iBufferIndex = 0;
    iOState = EOpening;
    iAmrFileOffset = 0;
    iPlayingOver = EFalse;

    // reset buffers
    for ( TInt i = 0 ; i < KStreamBufferCount ; i++ )
    iBuffers[ i ]->Zero();

    // reset measurement variables
    iUMiliseconds = 0;
    iUCount = 0;
    iUTotal = 0;

    iOutputStream->Open( &iStreamSettings );
    return KErrNone;
    }
    return KErrInUse;
    }

    There is nothing else to do. I hope you will solve the strange behaviour...
    Bye
    STeN

  6. #6
    Registered User
    Join Date
    Mar 2004
    Posts
    12
    Hi Sten,
    This is the same example I'm talking about.
    The problem occurs when you record inside buffer (iStreamBuffer in this example) and then play it.
    When you call PlayL(), it makes a call to Open() , but you never get
    MaoscOpenComplete()
    Just start the app, record 1-2 sec data and stop. Now just play it. You wont see the display changing to "Playing".

    I'm not talking about file operations. In my app, I record something and send to the server using TCP socket.
    I also receive audio data over the internet to be played. So you see there are no file operations involved. Everything would always be inside buffer.

    Thank you,
    Vikas

  7. #7
    Registered User
    Join Date
    Feb 2005
    Posts
    6
    Hi, everybody,

    I met a quite strange problem while using AudioInputStream during testing with audio stream example from Nokia. The impelementation of Nokia uses 3 buffers to store the audio data, when neccessary, rotation is needed. I suppose when I say "1,2,3", the first buffer will store "1", the second will store "2", and so on, but what I got is "1", noise, noise, I have enlarge the interval for the buffers to meet the content what I have to say, so I can ensure the data from the second, third buffer are not usual noise, I guess they are not filled with data. I also try another way to make some tests, I copy the data to other objects, when the callback of buffercopied was invoked, and reuse these 3 buffers to record more audio data, the result is "1", noise, noise, "1", noise(like the last time),noise(like the last time),... it seems the recorder just work once at the beginning. WHO has experiance to resolve this problem? Look forward to your help.
    The following is part of my code:
    ...MaiscBufferCopied(TInt aError, const TDesC8 & aRecordBuffer){
    if (aError==KErrNone) {
    // this buffer is for next recording process.
    TDes8* buffer;
    buffer = new(ELeave) TBuf8<KStreamBufferSize>;
    CleanupStack::PushL(buffer);
    buffer->SetMax();
    CleanupStack::Pop(buffer);
    // copy the content of the filled buffer
    HBufC8* temp = aRecordBuffer.AllocL();
    // check the copied buffer and put them into somewhere
    // do the next recording
    iInputStream->ReadL(*buffer);
    ....
    Is it right?

  8. #8
    Registered User
    Join Date
    Oct 2004
    Posts
    17

    Re: CMdaAudioInputStream & CMdaAudioOutputStream problem

    Hi Weahoo,

    I have found the reason to the problem.

    First we see the implementation of Record(), Stop(), Play()

    Record() ->Starts recording from the beginning of the buffer.
    iStreamStart = 0;
    iStreamEnd = iStreamBuffer.Count - 1
    (then loop back)

    Stop()-> This is the tricky function, which changes everything.
    iStreamStart = iStreamidx (NOTE THIS)
    iStreamEnd = iStreamBuffer.Count - 1

    Play()
    We strart from iStreamStrart(),
    and then loop back

    When we try to record data...assume we have 3 buffers, we filled 2 buffers with data, third is junk. So the buffer looks like: Data, Data, Noise.

    However, when we start playing,. the order is changed. IT PLAYS FROM WHERE WE STOPPED. So we have Noise, Data, data.


    The solution is to change iStreamStart = 0; in Stop();

    A piece of advice, if u really want to hear noise, change the no of buffers to around 30, and we can then record enough sound to clearly hear everything.

    Hope this helps,
    Sudha

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×