• AVR Freaks

bare minimum audio endpoint with rate feedback example

Page: 12 > Showing page 1 of 2
Author
stefanopod
Super Member
  • Total Posts : 1285
  • Reward points : 0
  • Joined: 2007/06/25 02:33:59
  • Location: Bologna,Italy
  • Status: offline
2011/01/05 08:54:43 (permalink)
0

bare minimum audio endpoint with rate feedback example

The only example of audio isochronous sink endpoint with feedback was posted on the forum years ago by sc6po.
This example is very well written but very badly explained, a lot of key details are missing and some uninportant details are wrong.
So I refurbished it and had it running, focusing the example only on the feedback issue.
I made further testing on a real life example, the feedback rate necessary to maintain a FIFO buffer of audio data, preventing overrun and underrun.It works fine, I think, but my audio is so bad that I hardly can test the quality.
So I share the complete code only for the minimum example testing the feedback endpoint, with a fixed feedback rate.
 
Anybody free to find errors, well possible, suggesting better solutions and so on.
 
Windows XP sp3; PIC 24fjgb002; usb stack 2.7a
page references to USB spec 2.0 and USB Audio spec 1.0
 
Input from a wav file to  41000 kHz speakers
 
       #define FEED_EP_SIZE 3   //format 10.14
#define MAX_PACKET_SIZE 45  //to catch 44 and 45 packets--also 46 is ok
#define FEED_EP_NUM 1
#define DATA_EP_NUM 1
#define _24F_1IN 0x18   //mask to select in transactions from U1STAT register #define WINDOW   10  //time period of in endpoint transactions=2exp10 //for real life examples better 7 #define FEED_ADDR     FEED_EP_NUM+0x80 //IN
#define DATA_ADDR     DATA_EP_NUM    //OUT   /* Device Descriptor */
ROM USB_DEVICE_DESCRIPTOR device_dsc=
{
   sizeof(USB_DEVICE_DESCRIPTOR),  // Size of this descriptor in bytes 0x12
   USB_DESCRIPTOR_DEVICE,  // DEVICE descriptor type 0x01
   0x0110,                 // USB Spec Release Number in BCD format 0x1001
   0x00,                   // Class Code
   0x00,                   // Subclass code
   0x00,                   // Protocol code
   USB_EP0_BUFF_SIZE,      // Max packet size for EP0 0x08
   0x1947,                 // Vendor ID
   0xab99,                 // Product ID
   0x0100,                 // Device release number in BCD format
   0x01,                   // Manufacturer string index
   0x02,                   // Product string index
   0x00,                   // Device serial number string index
   0x01                    // Number of possible configurations };   /* Configuration 1 Descriptor */
ROM BYTE configDescriptor1[] ={
   /* USB Speaker Configuration Descriptor */
   0x09,     // Size of this descriptor in bytes
   USB_DESCRIPTOR_CONFIGURATION,  // CONFIGURATION descriptor type
   0x6d,0x00,    // Total length takes care of feedback endpoint
   0x02,     // Number of interfaces in this cfg
   0x01,     // Index value of this configuration
   0x00,     // Configuration string index
   _DEFAULT | _SELF,   // Attributes, see usb_device.h
   0xFA,       // Max power consumption (2X mA)      /* USB Speaker Standard AControl Interface Descriptor */
   0x09,      // Size of this descriptor in bytes (bLength)
   USB_DESCRIPTOR_INTERFACE, // 0x04 INTERFACE descriptor type (bDescriptorType)
   AUDIO_CONTROL_INTERFACE_ID,   // 0 -Interface Number  (bInterfaceNumber)
   0x00,     // Alternate Setting Number (bAlternateSetting)
   0x00,     // Number of endpoints in this intf (bNumEndpoints)
   AUDIO_DEVICE,    // Class code  (bInterfaceClass) 0x01
   AUDIOCONTROL,    // Subclass code (bInterfaceSubclass) 0x01
   0x00,     // Protocol code  (bInterfaceProtocol)
   0x00,     // Interface string index (iInterface)      /* USB Speaker Class-specific AControl Interface Descriptor  */
 0x09,     // Size of this descriptor in bytes (bLength)
 CS_INTERFACE,    // CS_INTERFACE Descriptor Type (bDescriptorType) 0x24
 HEADER,     // HEADER descriptor subtype  (bDescriptorSubtype) 0x01
 0x00,0x01,    // Audio Device compliant to the USB Audio specification version 1.00 (bcdADC)
 0x1e,0x00,   //   Total number. (wTotalLength) //till to bandwidth 0 excluded
 0x01,      // The number of AudioStreaming interfaces  (bInCollection)
 0x01,     // AudioStreaming interface 1 belongs . (baInterfaceNr(1))    /* USB Speaker Input Terminal Descriptor   from where data come*/
 0x0C,     // Size of the descriptor, in bytes (bLength)
 CS_INTERFACE,      // CS_INTERFACE Descriptor Type (bDescriptorType) 0x24
 INPUT_TERMINAL,    // INPUT_TERMINAL descriptor subtype (bDescriptorSubtype) 0x02
 ID_INPUT_TERMINAL,   // ID of this Terminal.(bTerminalID) 0x01
 USB_STREAMING,     //    (wTerminalType) digital data from host
 0x00,     // No association (bAssocTerminal)
 0x01,     // One Channel (bNrChannels)
    0x00,0x00,           //(wChannelConfig)
 0x00,     // Unused.(iChannelNames)
 0x00,     // Unused. (iTerminal)
   /* USB Speaker Output Terminal Descriptor where data go*/
 0x09,     // Size of the descriptor, in bytes (bLength)
 CS_INTERFACE,    // CS_INTERFACE Descriptor Type (bDescriptorType) 0x24
 OUTPUT_TERMINAL,   // OUTPUT_TERMINAL  descriptor subtype (bDescriptorSubtype) 0x03
 ID_OUTPUT_TERMINAL,   // ID of this Terminal.(bTerminalID)  2
 SPEAKER,             //   (wTerminalType)See USB Audio Terminal Types.
 0x00,     // No association (bAssocTerminal)
 ID_INPUT_TERMINAL,// (bSourceID)01
 0x00,     // Unused. (iTerminal)    /* USB Speaker Standard AStreaming Interface Descriptor (Alt. Set. 0) */
 0x09,     // Size of the descriptor, in bytes (bLength)
 USB_DESCRIPTOR_INTERFACE,        // INTERFACE descriptor type (bDescriptorType) 0x04
 AUDIO_STREAMING_INTERFACE_ID,  // Interface Number  (bInterfaceNumber)
 0x00,     // Alternate Setting Number (bAlternateSetting)
 0x00,     // Number of endpoints in this intf (bNumEndpoints)
 AUDIO_DEVICE,   // Class code  (bInterfaceClass) 0x01
 AUDIOSTREAMING,   // Subclass code (bInterfaceSubclass) 0x02
 0x00,     // Protocol code  (bInterfaceProtocol)
 0x00,     // Interface string index (iInterface)    /* USB Speaker Standard AStreaming Interface Descriptor (Alt. Set. 1) */
 0x09,     // Size of the descriptor, in bytes (bLength)
 USB_DESCRIPTOR_INTERFACE,        // INTERFACE descriptor type (bDescriptorType) 0x04
 AUDIO_STREAMING_INTERFACE_ID,  // Interface Number  (bInterfaceNumber) 0x01
 0x01,     // Alternate Setting Number (bAlternateSetting)
  0x02,     // Number of endpoints in this intf (bNumEndpoints) data +feed
 AUDIO_DEVICE,   // Class code  (bInterfaceClass) 01
 AUDIOSTREAMING,   // Subclass code (bInterfaceSubclass) 02
 0x00,     // Protocol code  (bInterfaceProtocol)
  0x00,// Interface string index (iInterface)  /*  USB Speaker Class-specific AS General Interface Descriptor */
 0x07,     // Size of the descriptor, in bytes (bLength)
 CS_INTERFACE,   // CS_INTERFACE Descriptor Type (bDescriptorType)
 AS_GENERAL,    // GENERAL subtype (bDescriptorSubtype) 01
 ID_INPUT_TERMINAL,//  audio streaming--(bTerminalLink) 1
 0x01,     // Interface delay. (bDelay)
 0x02,0x00,    // PCM8 Format (wFormatTag) 1=BSOD    /*  USB Speaker Type 1 Format Type Descriptor */
 0x0B,     // Size of the descriptor, in bytes (bLength)
 CS_INTERFACE,   // CS_INTERFACE Descriptor Type (bDescriptorType) 0x24
 FORMAT_TYPE,   // FORMAT_TYPE subtype. (bDescriptorSubtype) 0x02
 0x01,     // FORMAT_TYPE_1. (bFormatType)
 0x01,     // one channel.(bNrChannels)
 0x01,     // 1 byte per audio subframe.(bSubFrameSize)
 0x08,     // 8 bits per sample.(bBitResolution)     
 0x01,     // One frequency supported. (bSamFreqType)
        0x44,
        0xac,
        0x00,      // Sampling Frequency = 41000 Hz(tSamFreq)   /*  USB Speaker Standard Endpoint Descriptor */
 0x09,     // Size of the descriptor, in bytes (bLength)
 USB_DESCRIPTOR_ENDPOINT,  // ENDPOINT descriptor (bDescriptorType)05
 DATA_ADDR,        // OUT 1 Endpoint  (bEndpointAddress)
        EP_ATTR_ISOCH|EP_ATTR_DATA|EP_ATTR_ASYNC,//(bmAttributes)pag 61 audio----pag 72 usb
 0x60,0x00,       // (wMaxPacketSize) >45
 0x01,        // One packet per frame.(bInterval)
 0x00,     // Unused. (bRefresh)
  FEED_ADDR,           // IN 01 Endpoint IN feedback  (bSynchAddress)    /* USB Speaker Class-specific Isoc. Audio Data Endpoint Descriptor*/
 0x07,     // Size of the descriptor, in bytes (bLength)
 CS_ENDPOINT,   // CS_ENDPOINT Descriptor Type (bDescriptorType) 0x25
 0x01,     // GENERAL subtype. (bDescriptorSubtype)
 0x00,     // No samp. freq. c., no pitch c., no packet padding.(bmAttributes)
        0x00,                //bLockDelayUnits pag 62 0,0,0 for async
        0x00,0x00,           //(wLockDelay) 
  
// Standard Audio Streaming (AS) isochronous sync endpoint descriptor pag 63
    0x09,             // Size of the descriptor, in bytes (bLength)
    USB_DESCRIPTOR_ENDPOINT,     //  (bDescriptorType)(0x05)
    FEED_ADDR,           //IN 01
    EP_ATTR_ISOCH|EP_ATTR_NO_SYNC,//pag 62 //EP_ATTR_ISOCH|EP_ATTR_FEEDBACK,// per scp60
    FEED_EP_SIZE,0x00,                    //size 3 bytes format 10.14
    0x01,                         //interval polling ms
    WINDOW,                         //brefresh 10=1024 ms
    0                             //bSyncAddress };   ////////////////////////////////////////////////////////// void USBCBInitEP(void)
{ USBEnableEndpoint(FEED_EP_NUM,USB_OUT_ENABLED|USB_IN_ENABLED|USB_HANDSHAKE_DISABLED|USB_DISALLOW_SETUP);  USBEnableEndpoint(DATA_EP_NUM,USB_IN_ENABLED|USB_OUT_ENABLED|USB_HANDSHAKE_DISABLED|USB_DISALLOW_SETUP);  USBISORxHandle = pBDTEntryOut[DATA_EP_NUM];
 USBFeedHandle = pBDTEntryIn[FEED_EP_NUM];
 USBFeedHandle=USBTxOnePacket(FEED_EP_NUM,pFeed,FEED_EP_SIZE);
 USBISORxHandle=USBRxOnePacket(DATA_EP_NUM,pPutInBuffer,MAX_PACKET_SIZE);
}   //////////////////////////////////////////////////////////////////////////////// BOOL USER_USB_CALLBACK_EVENT_HANDLER(USB_EVENT event, void *pdata, WORD size)
{   switch(event)
    {
        case EVENT_CONFIGURED:
            USBCBInitEP();
            break;
        case EVENT_TRANSFER:
        if((USTATcopy & 0x00F8)==_24F_1IN ) FeedBackEP();
          break;
        default:
          break;
    }     
    return TRUE;
}   //////////////////////////////////////////////////////////////////////
void UserInit(void)
{ //manual calculations, only for simplicity FeedBuffer[0]=0x60;//45100=0x60//44600=0x60//44100=0x60//43600=0x60//43100=0xc0;//different fequencies
FeedBuffer[1]=0x06;//45100=0x46//44600=0x26//44100=0x06//43600=0xe6//43100=0x85// assuming 1024 ms period of reset
FeedBuffer[2]=0x0b;//45100=0x0b//44600=0x0b//44100=0x0b//43600=0x0a//43100=0x0a//
//45.1->45.5//44.6->44.8//44.1->44.25//43.6->43.8//43.1->42.5//wanted->obtained
}//end UserInit
 
                       
/////////////////////////////////////////////////////////////////////////////////// void FeedBackEP(void)
{
//here calculations about the data amount received and  the needed new feedback  //for example feedback=data received over 128ms +=2  or -=2 if needed
        FromHost=0; //data amount reset
       if(!USBHandleBusy(USBFeedHandle))
               USBFeedHandle=USBTxOnePacket(FEED_EP_NUM,pFeed,FEED_EP_SIZE);//removing this BSOD
        } ///////////////////////////////////////////////////////////////////////////////////////////////////// void ProcessIO(void)
{ if(!USBHandleBusy(USBISORxHandle))
     {BytesActuallyRead=USBISORxHandle->CNT;//from last transaction
     FromHost+=BytesActuallyRead;;
     USBISORxHandle=USBRxOnePacket(DATA_EP_NUM,pPutInBuffer,MAX_PACKET_SIZE);
   }
}  


provando e riprovando
#1

26 Replies Related Threads

    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/11 09:41:06 (permalink)
    0
    but my audio is so bad that I hardly can test the quality.


    Async Sink expects re-sample on the host side.
    The base clock for DAC on the device is counted by a counter gated by SOF. The count is shifted to 10.10 format. It is fed back to the re-sampler on the host over synch IN EP, so that the host provides a number of samples on each USB frame, matched to the device local clock.
     

                                                                               Counter
                        +---------- synch IN EP <------ shift to    <-------- gated by SOF
                        |                               10.10 format               ^
                        |                                                          |
                        |                                                      Base clock
                     Feedback                                                      |
                        |                                                   Divider (/2^P)
                        |                                                          |
                        V                                                          V
    Audio Source ===(re-sample)===> isoc OUT EP ===(no re-sample)===> buffer ===> DAC ===> Speaker


    Rate conversion of this re-sampler on Windows built-in driver is known as a horrible one.
    It is one of the reason why ASIO (Audio Stream Input/Output) or WASAPI (Windows Audio Session API) are preferred for high-quality audio application.

    Tsuneo
    post edited by chinzei - 2011/01/11 10:00:20
    #2
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/11 11:34:18 (permalink)
    0
    but my audio is so bad that I hardly can test the quality.

     
    I meant that my audio hardware is very poor (quite noisy , pwm has a poor resolution and I listen through a headphone directly plugged into the pin of my PIC but - much better than I expected, though ), but i think that feedback performs well.
     
    The base clock for DAC on the device is counted by a counter gated by SOF

     
    In my case the base clock is asynchronous (a free running timer), gating to SOF could be done with a software/hardware PLL, but I think it's not strictly necessary.
     
    As I understand it , "resampling " means a kind of software interpolation/estrapolation to meet the needs of the device.
     
    It's a fact that the quality grows worse and worse as the frequency claimed from my device is different from the frequency embedded in the wav file.
    Host driver makes its best to be adaptive.
     
     
    Thanks for the insights.

    provando e riprovando
    #3
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/11 12:16:59 (permalink)
    0

    gating to SOF could be done with a software/hardware PLL, but I think it's not strictly necessary.

    It's absolutely necessary.
    Because, the frequency of the crystal on the device should slightly differ from the bus clock driven by another crystal on the host side, even when they have the same "frequency" printing on the chip.

    This difference causes overflow/underflow on the device buffer in long term.

    Tsuneo
    #4
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/11 13:40:44 (permalink)
    0
    I see, your suggestion is for the "synchronous endpoint" and I'm sure it's a good suggestion.
    But, as far as I know, a sink endpoint can be also async and in my case it's positively so.
    I employ feedback to prevent overflow/underflow on the device buffer.
    Is it so horrible?
    I think I can track overflows and I find them very seldom ,4 minutes or more with feedback, very often without feedback; if the song  isn't too long that's good.
    I adapted the only example found on the forum (from scp60).

    provando e riprovando
    #5
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/11 14:35:23 (permalink)
    0

    I see, your suggestion is for the "synchronous endpoint" and I'm sure it's a good suggestion.

    Not just Synchronous. SOF recovery is essential for all type of synchronization.
    For Async, the feedback is measured relatively to SOF, because the host provides data samples in SOF clock domain (ie. bus clock).

    I employ feedback to prevent overflow/underflow on the device buffer.

    See above figure. No feedback is taken from the number of data on the buffer.

    Above figure is the standard implementation of Async Sink, following USB spec. Feedback is taken from Base clock of DAC. Read this section of USB2.0 spec.

    5.12.4.2 Feedback (usb_20.pdf)
    An asynchronous sink must provide explicit feedback to the host by indicating accurately what its desired data rate (Ff) is, relative to the USB (micro)frame frequency.
    ...
    A sink can determine Ff by counting cycles of the master clock Fm for a period of 2^(K-P) (micro)frames. The counter is read into Ff and reset every 2^(K-P) (micro)frames.


    Tsuneo
    #6
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/12 02:26:16 (permalink)
    0
    I tried to send back as feedback the amount of samples sampled between a feedback request and the other ; anyway I found more effective to set a  upper/lower threshold to the buffer filling level and to ask a feedback progressively increased/decreased from the nominal rate to prevent under/overruns, so I don't need synchronism at all.
    Maybe it's unelegant but not completely uneffective.
    scp60's ideas,  French ideas, however.
     
    post edited by stefanopod - 2011/01/12 02:27:39

    provando e riprovando
    #7
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/12 03:34:02 (permalink)
    0
    Surely, the idea also indirectly measures the feedback relative to SOF interval.
    But you have to pre-buffer the data for more than 1 sec, to get accuracy of 1Hz, required for 10.10 format. Shorter pre-buffer causes oscillation of the feed back value around the true value, by the refresh period. It results distortion of sound, modulated by this oscillation.

    When you apply above standard feedback, the feedback value is accurately determined before the start of isoc streaming. Pre-buffer length is minimized.

    Tsuneo
    post edited by chinzei - 2011/01/12 03:40:51
    #8
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/12 04:18:11 (permalink)
    0
    Your kind answers push me to try again.
    It's "riprovando" time.

    provando e riprovando
    #9
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/13 10:02:11 (permalink)
    0
    I have tried again and the key question is that in the feedback system the return branch, that should have a "1" transfer (it's a follower), has a slightly different value, as for my simple tests reported on the post #1.
     
    //45.1->45.5//44.6->44.8//44.1->44.25//43.6->43.8//43.1->42.5//wanted->obtained

    The amount of data supplied from the driver follows the amount requested, but has a (prevalent) positive offset.
     
    Somewhere there is a bug, too  subtle for me.
     
    For this reason I have frequent overruns and the problem can be somehow avoided - a French workaround- basing the feedback not on the amount of data consumed, but on the difference between consumed and supplied (from the point of view of the theory introducing an integrating effect - pole ,zero (?), bringing to zero steady state error with all the Laplace transform stuff I have forgotten).
     
    A nice exercise should be having a proportional feedback  and building a linear model of it and making assumptions over rising time, overshoot, ringing etc,etc.
     
    Only for the records.

    provando e riprovando
    #10
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/18 11:29:42 (permalink)
    0
    I have REtried the example under Windows 7 and now everything works as it should.
    The problem of a considerable mismach between the frequency  requested via feedback and the actual USB throughput has disappeared, and my persistent problem of a buffer overrun has disappeared as well.
    No need now of a correction in the feedback request.
    I won't reinstall XP to verify again all the stuff, but I have more than  a suspicion that under XP feedback didn't work well.

    provando e riprovando
    #11
    sc6po
    Senior Member
    • Total Posts : 133
    • Reward points : 0
    • Joined: 2006/06/28 01:52:36
    • Location: France
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/28 06:02:22 (permalink)
    0
    Hi Stefano,
    I was just having quick visite, and I saw you were still on this...
    Seems you're having a nice stuff.
    On the feedback issue, I agree with you : there is no need for SOF sync.
    It's the opposite...
    Check out tis ling http://www.usbdacs.com/Concept/Concept.html sent to me by a guy on µChip Forum... Isoc Async  is the best! No need for SOF...

    On the feedback issue, you got to understand that the PC is usually faster. So your Nominal feedback will not be 1 but maybe 0.99 so that the PC runs slower... My bug was that I was sending a value too large, so the value was considered as an error.  If you send correct values as feedback (44.7 if buffer empty, 44.9- for normal and 45.1 for buffer full  should work with 44.8kHz audio)
    #12
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/28 07:18:39 (permalink)
    0
    Hi, French guy,
     glad to see you again.
     
    About point #1
    On the feedback issue, I agree with you : there is no need for SOF sync.

     
    Even if I don't employ SOF in my system , the requests made from audio driver to feedback endpoint are timed upon USB nothion of time, that is SOF. Not every frame but every 128/256/512 frames. So a link to SOF is always present.
     
    About point #1:
     
    In my opinion there is quite a difference in OS behaviour migrating from XP to windows 7.
    For example, while in XP I can put feedback refresh time to 1024 frames, under windows 7 I can only put 512 or less (????).
    In my experience windows 7 supplies such an exact feedback that a circular buffer isn't needed at all.
    With a simple 2 switching odd/even buffer scheme, I can measure the nember of the samples in a service time, and in the next service time I'll have exactly the number of bytes requested.
    USB audio specs explain in depth how fractions of frame are accumulated from a SOF to another, so I don't find how the rate should be slower or faster.
    Under XP your scheme based on a circular buffer and a feedback trimmed over buffer needs (greater or smaller than nominal) was necessary, owing to the lack of accuracy in the response of the driver.
    Of course I could well be wrong and my hardware is so poor that for shure I can't test in depth the quality of my audio.
    That's why I'm QUITE SATISFACTED about the results of my work.
    Occhio non vede cuore non duole/ Si l'oeil ne voit pas, le coeur n' a pas de peine.
    post edited by stefanopod - 2011/01/28 09:02:14

    provando e riprovando
    #13
    sc6po
    Senior Member
    • Total Posts : 133
    • Reward points : 0
    • Joined: 2006/06/28 01:52:36
    • Location: France
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/29 06:57:39 (permalink)
    0
    Hi,
    Since I was working on Linux and never tried on windows, I just can't answer about XP or Vista/7...
    About SOF, I understood maybe something different...
    The thing is you do not need SOF. You only need to receive data...Since the isochronous rate is x data per ms, and SOF is 1 per ms, you can always say there is a relationship, but there is no direct link between SOF and Feedback.

    What I understood from SOF recovery is that some devices uses SOF to synchronise. These are Isoc Sync devices. They use SOF to erase clock drift issue. But this bring jitter and distorsion.
    About the prebuffer and 1Hz issue : this is due to Isoc Async with adaptive on device side... You sligthly change the clock on device side in order to adjust the device clock to match the host clock. For this you need the 1Hz...You do not necessarly need to prebuffer if you can change your clock live...

    With Isoc Async with feedback, this is the host that adapts its speed (not the clock, but the data rate), so everyting is done on host side.
    . Like it is said in the USBDACS link I posted above, you can use the device clock that can be a low jitter clock, a nearly perfect clock. 
    This works perfect with music. I was working with phones, and it worked perfect with phones.

    The only issue I had was solved later...I was sending a wrong value to the host, so that I was able to adapt the speed to request slower speed...But my value to request faster was wrong and I could not go faster...So whenever I had lost a data paquet, I could not get faster and recover...Maybe you can check this in your system. Check that the value send for regulation is within the limits, so that the host can handle it, and not consider it is an incorrect value.

    About the feedback value, like you said, the method used to compute the speed may not be sexy, not computed with complex alogorythm to get the perfect speed, but it is by far the most efficient. You always correct the value wanted, but at least you can correct for lost packets... And believe me, even if I used 8kHz codec, the sound was really nice...

    Bye






    #14
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/29 09:57:04 (permalink)
    0

    Since the isochronous rate is x data per ms, and SOF is 1 per ms,

    Not exactly. 
    USB spec defines SOF interval as 1.00 ms +/- 0.0005 ms
    (8.4.3 Start-of-Frame Packets, usb_20.pdf)

    If the SOF interval would be exactly 1 ms, the thing could be so simple as you said.
    Isoc data stream is provided upon this SOF interval with error. Therefore, to know exact data rate (sampling rate) on the bus, device has to measure SOF interval directly or indirectly, regardless of synchronization scheme.

    For Async Sink, the DAC sampling rate is measured relative to SOF interval. And it is passed to the Synch EP for feedback. Even if you are just counting the number of data on isoc stream, the data is provided in SOF interval. In this case also, the feedback is determined relative to SOF interval, indirectly.

    You sligthly change the clock on device side in order to adjust the device clock to match the host clock.

    How long does it take, until the feedback is stabilized, when you change the feedback slightly on every SOF?
    Until it is stabilized, the device drops data (overflow) or it adds extra data (underflow).
    Your device is always out of tune for a couple of seconds of the start of music wink

    Tsuneo
    post edited by chinzei - 2011/01/29 09:58:11
    #15
    sc6po
    Senior Member
    • Total Posts : 133
    • Reward points : 0
    • Joined: 2006/06/28 01:52:36
    • Location: France
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/29 10:45:23 (permalink)
    0
    I have to agree with you on the fact that if you follow USB spec instructions, you got to compute the desired sampling rate. For this to be done correctly, you got to wait for seconds in order to compute an accurate frequency...
    But...
    The nice thing with Isoc Async is that you do not have to do it this way.
    You got your DAC clock, that is important and that has to be good (at least if you want to have a nice sound).
    Then, the only thing you got to consider is to feed the DAC... -> Use a Buffer

    Nothing is important but :
         - to have enough data to feed the DAC => Buffer not empty
         - not to have too much data => avoid buffer full.
    Anyway you can handle this task is a good way.

    I tried to compute the perfect sampling rate => this was hardly done, and not effective.
    I tried to get different values depending wether the buffer is half full, 3/4 full...
    But nothing was better than   More-Nominal-Less ...

    You do not need the compute the rate. You just ask more or less. You start to feed the dac just after you have your buffer half full (two packets of data is enough, aka 2ms)...
    You got to believe me when I say that the job was done perfectly with phone (Voice Over IP)...Sure, someone had to make computations to deal with clock drift between computers over the net...But this was done by the computer, not by the µChip...

    The real amazing thing with this, is that this way of doing things is by far the most simple.
    Since it also happens to be the best for sound quality... (USBDACS says so...)

    But sometimes, simple is hard to achieve...





    post edited by sc6po - 2011/01/29 10:54:23
    #16
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/29 14:37:41 (permalink)
    0
    The real amazing thing with this, is that this way of doing things is by far the most simple.
    Since it also happens to be the best for sound quality... (USBDACS says so...)


    Really I don't find your idea so simple, a lot of parameters have to be set properly, with different possible results.
     
    And being your system very hard to be modeled, all has to be done empirically.
     
    Though respecting USBDACS authority , I would like to have the capability (that I haven't) of testing in real life rise time, ringing, overshoot of your system response.
    And, of course, of my primitive odd/even buffer system.

    provando e riprovando
    #17
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/29 20:50:56 (permalink)
    0

    The original Async Sink, described in the USB spec, assigns just a simple comparator role to the device in the feedback loop. You add another control into the feedback loop. It makes the feedback loop unstable.

    The real amazing thing with this, is that this way of doing things is by far the most simple.

    If you would follow the original Async Sink.
    But sometimes, simple is hard to achieve...

    You make the simple original system into complicated one.wink

    Tsuneo
    post edited by chinzei - 2011/01/29 20:52:28
    #18
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/30 00:47:06 (permalink)
    0
    The problem is how accurate is the response of the OS.
     
    An example:
     
    My consuming at 44105, OS sending data 44100, no feedback--->problem
     
    with ACCURATE feedback: my consuming 44105, feedback request 44105, OS response 44105-->circular buffer useless
     
    with UNACCURATE feedback: my consuming 44105, my request 44105, os response 44106--->in this case there is a problem for odd/end, no problem for circular buffer where the request will be sometimes  44103,44104,44105  and the response, as an average, 44105.
     
    In real life I don't know how big is the real need of a correction over the ideal case, even less the need of a correction over the correction.
     
     
     

    provando e riprovando
    #19
    sc6po
    Senior Member
    • Total Posts : 133
    • Reward points : 0
    • Joined: 2006/06/28 01:52:36
    • Location: France
    • Status: offline
    Re:bare minimum audio endpoint with rate feedback example 2011/01/30 04:22:31 (permalink)
    0
    Don't think about the circular buffer. This is another solution I brang to my system...
    If you can afford to have Odd/Even buffers, this might be enought. I could not since I had too much data.

    I do not see what you want to check for rise time/ringing/overshoot... I clearly don't see what this would bring you...
    The only important thing is how good is your sound reproduction, and can you handle data loss...

    With my system, sound reproduction is good, and data loss is handled by increasing speed in order to full the buffer...






    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5