Re: 96kHz 24bit WAV playback

John Stirling <[email protected]>
Newsgroups gmane.comp.multimedia.helix.devel
Message-ID <[email protected]>
So pcmrend.cpp now claims 'audioL24'. wvffplin.cpp correctly sets the 
mimetype to this. The track now looks like it is playing but no audio 
comes out. It also plays for the correct amount of time. So, some progress..

Current problem seems to be that hxaudses.cpp never attempts to open the 
audio device in 24 bit mode.

Looking at hxaudses.cpp (GetDeviceFormat) there a comment at the top -

// We no longer force audio device in stereo mode. However we
// still try to open it in 16-bit mode since all of our processing
// is done in 16 bit.
m_DeviceFmt.uBitsPerSample = 16;

I'm just about to try and work out what's going on in that function, but 
any pointers would be appreciated.

Can you envisage any problems in us allowing it to attempt to open the 
device in 24 bit mode ? Note we are going to arrange it so that we can 
generate clocks for all sample rates so that we can ensure the resampler 
never gets invoked - we presumed this would reduce problems for us.


pcmfmt.cpp:Init ENTRY
pcmfmt.cpp:Init rv=00000000
pcmfmt.cpp:Init getting mime type
pcmfmt.cpp:Init pszMimeType=audio/L24
pcmfmt.cpp:Init 10
pcmfmt.cpp:Init 12
pcmfmt.cpp:Init EXIT 00000000
hxaudses.cpp:CheckAudioFormat
hxaudses.cpp:CheckAudioFormat pFormat->uBitsPerSample=16
hxaudses.cpp:CheckAudioFormat pFormat->ulSamplesPerSec=30464
hxaudev.cpp:CheckFormat
hxaudev.cpp:CheckFormat pFormat->uBitsPerSample=16
hxaudev.cpp:CheckFormat pFormat->ulSamplesPerSec=30464
audUnix.cpp:_Imp_CheckFormat
audUnix.cpp:_Imp_CheckFormat pFormat->uBitsPerSample=16
audUnix.cpp:_Imp_CheckFormat pFormat->ulSamplesPerSec=30464
audlinux_oss.cpp:_CheckFormat
audlinux_oss.cpp:_CheckFormat pFormat->uBitsPerSample=16
audlinux_oss.cpp:_CheckFormat pFormat->ulSamplesPerSec=30464
hxaudev.cpp:Open
hxaudev.cpp:Open pFormat->uBitsPerSample=16
hxaudev.cpp:Open pFormat->ulSamplesPerSec=30464
audUnix.cpp:_Imp_Open
audUnix.cpp:_Imp_Open pFormat->uBitsPerSample=16
audUnix.cpp:_Imp_Open pFormat->ulSamplesPerSec=30464
audlinux_oss.cpp:_SetDeviceConfig
audlinux_oss.cpp:_SetDeviceConfig REQUESTED
audlinux_oss.cpp:_SetDeviceConfig pFormat->uBitsPerSample=16
audlinux_oss.cpp:_SetDeviceConfig pFormat->ulSamplesPerSec=30464
audlinux_oss.cpp:_SetDeviceConfig Setting format
audlinux_oss.cpp:_SetDeviceConfig nFormat1=16
audlinux_oss.cpp:_SetDeviceConfig nFormat2=16

========Source 0========
====File Header====
StreamCount 1
Flags 1
====Stream 0====
StreamNumber 0
MaxBitRate 4608000
AvgBitRate 4608000
MaxPacketSize 11520
AvgPacketSize 11520
StartTime 0
Preroll 2000
Duration 65177
BitsPerSample 24
SamplesPerSecond 96000
Channels 2
RTPPayloadType 101
TrackEndTime 65177
PostDecodeDelay 1000
MimeType audio/L24





Eric Hyche wrote:
> John,
>
> Yes, that sounds like the correct approach:
>
> 1) Have wav file format (wvffplin.cpp) report a mime type
>    of "audio/L24" and properly set other stream header parameters
> 2) Add RFC3190 support (this is the RFC which specifies audio/L24)
>    to the PCM renderer. This would include:
>      a) claiming "audio/L24" as a supported stream mime type
>      b) properly translating the audio/L24 packets into IHXAudioStream::Write() calls
>
> Eric
>
> =======================================
> Eric Hyche ([email protected])
> Principal Engineer
> RealNetworks, Inc.
>
>
>   
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of John Stirling
>> Sent: Monday, March 30, 2009 1:22 PM
>> To: [email protected]
>> Subject: Re: [Helix-client-dev] 96kHz 24bit WAV playback
>>
>> Taking a standard 16 bit 44.1khz .wav file I've hand edited to report 24
>> bit 96khz -
>>
>> (.wav raw hex field)
>> Bits/sample = 0x18 0x00
>> SampleRate= 0x00 0x77 0x01 0x00
>> ByteRate = 0x00 0xca 0x08 0x00
>>
>> If I edit wvffplin.cpp as follows it gets through to the renderer.
>>
>> I presume what I need to do is report audio/L24 from wvffplin.cpp and
>> make audrend.cpp claim (and render) audio/L24. Does that sound correct ?
>>
>>
>> (wvffplin.cpp)
>>
>>        ///////////////////////////////
>>        // This wave file is raw PCM //
>>        ///////////////////////////////
>>
>>        // Don't set any opaque data
>>        HX_RELEASE(pHeaderBuf);
>>
>>        // Set appropriate mime type
>>        if (nBitsPerSample == 8)
>>        {
>>            pMimeType = "audio/L8";
>>        }
>>        else if (nBitsPerSample == 16)
>>        {
>>            pMimeType = "audio/L16";
>>
>>            // Remember to make all data net-endian
>>            m_bSwapSamples = TRUE;
>>        }
>>        else if (nBitsPerSample == 24) //XXX
>>        {
>>
>>            pMimeType = "audio/L8";
>>        }
>>
>>
>> (audrend.cpp)
>> const char* const CPCMAudioRenderer::m_ppszStreamMimeTypes[] = {
>> "audio/L8", "audio/L16", "audio/x-pn-wav",
>> "audio/PCMA","audio/pcma","audio/PCMU",NULL };
>>
>>
>>
>> John Stirling wrote:
>>     
>>> Hi Greg,
>>>
>>> OK thanks. I don't really have time to dig too much into this either
>>> at the moment unfortunately. I guess we just say no to this for now
>>> unless our customer wants to investigate themselves..
>>>
>>> John.
>>>
>>>
>>> Greg Wright wrote:
>>>       
>>>> John Stirling wrote:
>>>>         
>>>>> Any chance we could get a comment from one of your experts on .wav
>>>>> playback (Jon/Ken I presume) before we start digging into this any
>>>>> more ?
>>>>>
>>>>>           
>>>> John,
>>>>
>>>> I don't have time to dig too deep, but I downloaded the file
>>>>
>>>>    Test_File_2_0_STEREO_PCM.wav
>>>>
>>>> from http://www.itrax.com/Pages/HelpFAQs.php#1 (PCM 96/24 2.0 stereo)
>>>>
>>>>
>>>> It won't play back in splay because of a failure in:
>>>>
>>>>     HX_RESULT CPCMAudioFormat::Init(IHXValues* pHeader)
>>>>
>>>>
>>>> It does:
>>>>
>>>>       retVal = pHeader->GetPropertyCString("MimeType", pMimeTypeStr);
>>>>
>>>> then:
>>>>
>>>>            else if (!strcmp(pszMimeType, "audio/x-pn-wav"))
>>>>             {
>>>>                 m_ucMimeType = kMimeTypeAudioXPNWav;
>>>>             }
>>>>
>>>> Finally:
>>>>
>>>>                 // Get the opaque data
>>>>                 IHXBuffer* pBuffer = NULL;
>>>>                 retVal = pHeader->GetPropertyBuffer("OpaqueData",
>>>> pBuffer);
>>>>                 if (SUCCEEDED(retVal))
>>>>
>>>>
>>>> There appears to be no OpaqueData, it returns HXR_FAIL, and ends
>>>> up returning that error back up the chain. It does that for 2
>>>> renderers.
>>>>
>>>> Not sure if that is much of a clue or not.
>>>>
>>>> --greg.
>>>>
>>>>
>>>>
>>>>         
>>>>> Eric Hyche wrote:
>>>>>           
>>>>>> Hard to tell when using PC RealPlayer as comparison. It
>>>>>> uses DirectX to play back .wav files, and not Helix,
>>>>>> the Windows RealPlayer might be able to play it back
>>>>>> but Helix still might not.
>>>>>>
>>>>>> If the changes suggested below by Greg didn't work,
>>>>>> then further investigation is needed to find out
>>>>>> why.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> =======================================
>>>>>> Eric Hyche ([email protected])
>>>>>> Principal Engineer
>>>>>> RealNetworks, Inc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: [email protected]
>>>>>>> [mailto:[email protected]]
>>>>>>> On Behalf Of John Stirling
>>>>>>> Sent: Tuesday, December 23, 2008 4:14 AM
>>>>>>> To: [email protected]
>>>>>>> Subject: Re: [Helix-client-dev] 96kHz 24bit WAV playback
>>>>>>>
>>>>>>> I heard a rumour that the PC real player now supports 24/96
>>>>>>> playback ?
>>>>>>>
>>>>>>> If so, is it possible to port those changes to cayenne ?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> John Stirling wrote:
>>>>>>>
>>>>>>>               
>>>>>>>> I added 96000 into that list but still can't play the file.
>>>>>>>>
>>>>>>>> Is there anything else easy to try ?
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> John Stirling wrote:
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Thanks (I remember that list)
>>>>>>>>>
>>>>>>>>> re 24 bit -
>>>>>>>>>
>>>>>>>>> . if the audio device only supports 16 bit would you expect the
>>>>>>>>> core/resampler to handle that ?
>>>>>>>>> . if the audio device supports 24 bit would the core be able to
>>>>>>>>> output in 24 bit ?
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Greg Wright wrote:
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> From hxaudses.cpp:
>>>>>>>>>>
>>>>>>>>>> const unsigned short z_anValidSampleRates[] = { 8000,
>>>>>>>>>>                                                 11025,
>>>>>>>>>>                                                 16000,
>>>>>>>>>>                                                 22050,
>>>>>>>>>>                                                 32000,
>>>>>>>>>>                                                 44100,
>>>>>>>>>>                                                 48000,
>>>>>>>>>>                                                 49512
>>>>>>>>>>                                               };
>>>>>>>>>>
>>>>>>>>>> You might need to expand that list at least.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --greg.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> John Stirling wrote:
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> I tried a sample track on RealPlayer10 on windows and it
>>>>>>>>>>> didn't work.
>>>>>>>>>>>
>>>>>>>>>>> The same track could play ok via itunes, but not via WMP10.
>>>>>>>>>>>
>>>>>>>>>>> See:
>>>>>>>>>>> http://www.itrax.com/Pages/HelpFAQs.php#1
>>>>>>>>>>> for track we're trying to play
>>>>>>>>>>>
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Eric Hyche wrote:
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> I was hoping someone else would answer, since
>>>>>>>>>>>> I'm not 100% certain of my answer... :-)
>>>>>>>>>>>>
>>>>>>>>>>>> If you are talking about playing back a raw
>>>>>>>>>>>> 96kHz 24-bit-per-sample .wav file, then I can't
>>>>>>>>>>>> think of a reason that *wouldn't* work, assuming
>>>>>>>>>>>> the audio device could be opened at 96kHz
>>>>>>>>>>>> and 24bits. If it couldn't be, then it would
>>>>>>>>>>>> have to go through a few other layers of the
>>>>>>>>>>>> system (resampler, etc.) which I *believe* suport
>>>>>>>>>>>> this format, but I'm not sure.
>>>>>>>>>>>>
>>>>>>>>>>>> Jon/Ken: do you know if this would work, or
>>>>>>>>>>>> have you ever tried 96kHz/24-bit playback?
>>>>>>>>>>>>
>>>>>>>>>>>> Eric
>>>>>>>>>>>>
>>>>>>>>>>>> =============================================
>>>>>>>>>>>> Eric Hyche ([email protected])
>>>>>>>>>>>> Technical Lead
>>>>>>>>>>>> RealNetworks, Inc.
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: [email protected]
>>>>>>>>>>>>> [mailto:[email protected]] On
>>>>>>>>>>>>> Behalf Of
>>>>>>>>>>>>> John Stirling
>>>>>>>>>>>>> Sent: Friday, January 18, 2008 5:04 AM
>>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>> Subject: Re: [Helix-client-dev] 96kHz 24bit WAV playback
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any response on this ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> John Stirling wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> Is 96khz, 24bit WAV supported on cayenne1_5_0 ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seems a bit excessive, but someone is asking..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Helix-client-dev mailing list
>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Helix-client-dev mailing list
>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Helix-client-dev mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> _______________________________________________
>>>>>>>>> Helix-client-dev mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> _______________________________________________
>>>>>>>> Helix-client-dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>>
>>>>>>>>                 
>>>>>>> _______________________________________________
>>>>>>> Helix-client-dev mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>
>>>>>>>               
>>>>>>             
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Helix-client-dev mailing list
>>>>> [email protected]
>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>           
>>> _______________________________________________
>>> Helix-client-dev mailing list
>>> [email protected]
>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>       
>> _______________________________________________
>> Helix-client-dev mailing list
>> [email protected]
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>     
>
>

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.