Peter Stuge | 21 May 23:42
Picon

Do you need a product ID for your open source project?

You can ask Openmoko for one:

http://wiki.openmoko.org/wiki/USB_Product_IDs#Open_registry_for_community_.2F_homebrew_USB_Product_IDs

//Peter

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
John Stirling | 21 May 18:14

interrupt transfers

Hi,

 

I'm having an issue with occasional lost interrupt transfers. On a USB analyser I can see the problem occurs when two interrupt transfers come in fairly close to each other (approx 1ms gap).

 

Currently I am stacking up several (10) interrupt transfer requests at initialisation and then just resubmitting them every time I get a callback.

 

Setup -

 

#define HID_RX_BUFFER_SIZE 512

 

static void vRequestHIDData(int iIndex)

{

  libusb_device_handle *ptDeviceHandle = [poUSBDevice ptGetDeviceHandle];

  unsigned int uiHIDEndpoint = [poUSBDevice uiGetHIDEndpoint];

 

  struct libusb_transfer *ptTransfer = g_atHIDRxTransfers[iIndex].ptTransfer;

  u8 *pu8Buffer = g_atHIDRxTransfers[iIndex].pu8Data;

 

  // Reload the transfer

  libusb_fill_interrupt_transfer(ptTransfer,        // transfer

                                 ptDeviceHandle,         // dev_handle

                                 uiHIDEndpoint,        // endpoint

                                 pu8Buffer,           // buffer

                                 HID_RX_BUFFER_SIZE,     // length

                                 vHIDRxCallback,   // callback

                                 (void *)iIndex,        // user_data

                                 500                    // timeout

                                );

 

  libusb_submit_transfer(ptTransfer);

}

 

Resubmission:

static void vHIDRxCallback(struct libusb_transfer *ptTransfer)
{
  int iLength = ptTransfer->actual_length;
  int iIndex = (int)ptTransfer->user_data;

  if (ptTransfer->status != LIBUSB_TRANSFER_TIMED_OUT)
  {
    vLOG_STATIC_FUNC_VA("### HID RX (%d) l=%d s=%d ###", iIndex, iLength, ptTransfer->status);
    if (bLOG_IsLoggingEnabledHere())
      vUTL_DumpHex(ptTransfer->buffer, iLength);
  }

  // Send it on to main app thread
  write(iWriteFD, ptTransfer->buffer, iLength);

  // and set up to receive more HID data
  libusb_submit_transfer(ptTransfer);
}

If I set different timeouts for each transfer i can see the previously missing transfers. eg

static void vRequestHIDData(int iIndex)

{

  libusb_device_handle *ptDeviceHandle = [poUSBDevice ptGetDeviceHandle];

  unsigned int uiHIDEndpoint = [poUSBDevice uiGetHIDEndpoint];

 

  struct libusb_transfer *ptTransfer = g_atHIDRxTransfers[iIndex].ptTransfer;

  u8 *pu8Buffer = g_atHIDRxTransfers[iIndex].pu8Data;

 

  // Reload the transfer

  libusb_fill_interrupt_transfer(ptTransfer,        // transfer

                                 ptDeviceHandle,         // dev_handle

                                 uiHIDEndpoint,        // endpoint

                                 pu8Buffer,           // buffer

                                 HID_RX_BUFFER_SIZE,     // length

                                 vHIDRxCallback,   // callback

                                 (void *)iIndex,        // user_data

                                 (100*iIndex)                    // timeout

                                );

 

  libusb_submit_transfer(ptTransfer);

}

I suspect my initial attempty was failing due to all 10 transfers timing out at approx the same time and not being resubmitted quick enough ?

Is there an example somewhere showing interrupt transfers stacked up and resubmitted ? Although setting different timeouts is getting me past this problem I suspect I might need to recalculate the timeout on each resubmission to ensure there are a certain number outstanding at all times ?

Thanks,
John

 

 

 

 

 

 

 



Audio Partnership PLC, Gallery Court, Hankey Place, London SE1 4BB, UK Reg No. 2953313 This e-mail is confidential and for the addressee only. Please refer to Disclaimer for important notices.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
Xiaofan Chen | 13 May 13:53
Picon

[PATCH] libusb-compat-0.1 examples: Link only with ../libusb/libusb.la and not with -lusb

commit e01ea627d1c5caac9492870b315353173e7b8a61
Author: Xiaofan Chen <xiaofanc <at> gmail.com>
Date:   Sun May 13 19:50:38 2012 +0800

        modified:   examples/Makefile.am
    This is similar to the following libusb-1.0 patch.
    http://git.libusb.org/?p=libusb.git;a=commitdiff;h=93b0e09d53ed1d177631af918

    Previous _LDFLAGS included both the freshly built libusb in ../libusb
    and -lusb, where libtool would usually resolve the latter to an
    already-installed libusb library in the system. The extra reference
    to a second libusb library may cause failures to build examples
    on some platforms and is wrong.

diff --git a/examples/Makefile.am b/examples/Makefile.am
index 3023b58..5292cef 100644
--- a/examples/Makefile.am
+++ b/examples/Makefile.am
@@ -2,8 +2,8 @@ INCLUDES = -I$(top_srcdir)/libusb
 noinst_PROGRAMS = lsusb testlibusb

 lsusb_SOURCES = lsusb.c
-lsusb_LDADD = ../libusb/libusb.la -lusb
+lsusb_LDADD = ../libusb/libusb.la

 testlibusb_SOURCES = testlibusb.c
-testlibusb_LDADD = ../libusb/libusb.la -lusb
+testlibusb_LDADD = ../libusb/libusb.la

--

-- 
Xiaofan

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Peter Stuge | 11 May 20:29
Picon

[pete <at> akeo.ie: Re: [Libusbx-devel] [PATCH] Add topology calls]

Pete removed the libusb list as recipient in his reply, so I'm forwarding.

----- Forwarded message from Pete Batard <pete <at> akeo.ie> -----

To: libusbx-devel <at> lists.sourceforge.net
Subject: Re: [Libusbx-devel] [PATCH] Add topology calls
Date: Fri, 11 May 2012 19:26:24 +0100

On 2012.05.11 19:08, Peter Stuge wrote:
> This means taking some risks
> ..as opposed to erring on the side of caution

And you'll be free to take risks and live on the edge, for what is 
really a minor detail not worth spending much time on, when/if you carry 
the API in libusb. Your suggestion has been heard, and, as ever, I'm 
puzzled as to why you're trying to blow such a minor API item out of 
proportion, just to attempt to get "your way" in a project that had to 
fork precisely because of this behaviour.

> I think it's too limited for the API to be worthwhile. It introduces
> a unique restriction not seen previously in the libusb API.

Well, if people vote to have get_parent to be removed from the public 
API because they see it too limiting, and we don't get user requests 
otherwise in the meantime, I don't have a problem keeping it private and 
reviewing its introduction to the public API once we have hotplug and an 
overhauled enum. But that only applies to get_parent.

Regards,

/Pete

----- End forwarded message -----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Peter Stuge | 11 May 17:50
Picon

[peter <at> stuge.se: Re: [Libusbx-devel] [PATCH] Add topology calls]

Pete proposed some new topology APIs in libusbx, and I sent some
comments and questions about them to their mailing list. I'm
forwarding to the libusb-devel list in order to hear from more people
- maybe you can answer my questions or have other thoughts on the
proposal.

Thanks!

//Peter

----- Forwarded message from Peter Stuge <peter <at> stuge.se> -----

To: libusbx-devel <at> lists.sourceforge.net
Subject: Re: [Libusbx-devel] [PATCH] Add topology calls
Date: Fri, 11 May 2012 17:48:17 +0200

Pete Batard wrote:
> +int API_EXPORTED libusb_get_port_path(libusb_context *ctx, libusb_device *dev, uint8_t* path,
uint8_t path_len)

I think the proposed API could be simplified. There's a hard upper
limit on the path length (7 ports including the HC) so I would
suggest to drop the path_len input parameter and document that path
must be uint8_t [7] or longer.

> +	/* The device needs to be open, else the parents may have been destroyed */

Please explain this comment in more detail? Does it refer to the
libusb_device refcounting?

> +libusb_device * LIBUSB_CALL libusb_get_parent(libusb_device *dev)
> +{
> +	return dev->parent_dev;
> +}

Are all devices refcounted by their children?

//Peter

----- End forwarded message -----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
madhav chauhan | 10 May 09:15
Picon

Query: Getting Hot Plug/Unplug notification for USB device

Hi All,
I am trying to get  notification whenever any USB device hot plugged
in or plugged out.
I used  LIBUSB API: libusb_set_pollfd_notifiers() in the following
manner but i get event only whenever any device plugged out not for
plug in.

/*Code Snippet*/
libusb_context *ctx
retval = libusb_init(&ctx);
libusb_pollfd_added_cb device_AddedCalBack;
libusb_pollfd_removed_cb deviceRemovedCallBack;

 device_AddedCalBack = &sample_libusb_pollfd_added_cb;
 deviceRemovedCallBack = &sample_libusb_pollfd_removed_cb;
 //register hot plug and unplug events.
 if(retval ==0){
dbg_printf(TRC_VERBOSE, TRC_FLAGS_MUX, "****Calling
libusb_set_pollfd_notifiers \n");
 libusb_set_pollfd_notifiers(ctx, device_AddedCalBack,
deviceRemovedCallBack, (void*)ctx);
dbg_printf(TRC_VERBOSE, TRC_FLAGS_MUX, "****Call
libusb_set_pollfd_notifiers returned %d \n",retval);

Regards,
Madhav

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
John Stirling | 8 May 18:03

isochronous transfers

Hi,

I'm attempting to use libusb-1.0 to stream audio data from an isochronous endpoint :

Endpoint Descriptor (Audio):
------------------------------

Value Valuename
0x09 bLength
0x05 bDescriptorType
0x83 bEndpointAddress   (In-Endpoint)
0x01 bmAttributes
   Transfer Type:           Isochronous-Transfer
   Synchronization Type:    None
   Usage Type:              Data
0x00C0     wMaxPacketSize   (192 Bytes)
0x01 bInterval
0x00 bRefresh
0x00 bSynchAddress
Hex dump:
0x09 0x05 0x83 0x01 0xC0 0x00 0x01 0x00 0x00

(I'm using http://git.tuxfamily.org/microdiausp/microdiauserspace.git as an example of how to drive isochronous transfers.)

As per above example, two transfers are set up via

  uiAudioEndpoint = 0x83;
  iMaxAudioPackets = 10;
  libusb_device *ptDevice = [poUSBDevice ptGetDevice];
  iMaxIsoPacketSize = libusb_get_max_iso_packet_size(ptDevice, uiAudioEndpoint);
  iAudioBufferLength = iMaxIsoPacketSize * iMaxAudioPackets;
  int i;
  for (i=0; i<NUM_TRANSFERS; i++)
  {
    atTransfers[i].ptAudioTransfer = libusb_alloc_transfer(iMaxAudioPackets);
    atTransfers[i].pu8AudioData = g_malloc(iAudioBufferLength);
  }

Transfers are filled in and submitted as follows -

static void vRequestAudioData(int iIndex)
{
  libusb_device_handle *ptDeviceHandle = [poUSBDevice ptGetDeviceHandle];

  uiAudioEndpoint = 0x83;
  vLOG_STATIC_FUNC_VA("h=%p uiAudioEndpoint=0x%02x", ptDeviceHandle, uiAudioEndpoint);

  struct libusb_transfer *ptAudioTransfer = atTransfers[iIndex].ptAudioTransfer;
  u8 *pu8AudioData = atTransfers[iIndex].pu8AudioData;

  // Reload the transfer
  libusb_fill_iso_transfer(ptAudioTransfer,        // transfer
                           ptDeviceHandle,         // dev_handle
                           uiAudioEndpoint,        // endpoint
                           pu8AudioData,           // buffer
                           iAudioBufferLength,     // length
                           iMaxAudioPackets,       // num_iso_packets
                           vAudioTransferCallback,   // callback
                           (void *)iIndex,           // user_data
                           500                       // timeout
                          );
  libusb_set_iso_packet_lengths(ptAudioTransfer, iMaxIsoPacketSize);
  ptAudioTransfer->num_iso_packets = iMaxAudioPackets;
  ptAudioTransfer->type |= LIBUSB_TRANSFER_TYPE_ISOCHRONOUS;

  libusb_submit_transfer(ptAudioTransfer);
}

Then libusb kicked via eg

  while (1)
  {
    libusb_handle_events(ptContext);
  }

Audio transfers are handled as follows -

static void vAudioTransferCallback(struct libusb_transfer *ptTransfer)
{
  int iCount = 0;
  int iIndex = (int)ptTransfer->user_data;

  int i;
  for (i=0; i<iMaxAudioPackets; i++)
  {
    int iStatus = ptTransfer->iso_packet_desc[i].status;
    int iLength = ptTransfer->iso_packet_desc[i].actual_length;

    if (iStatus == 0)
    {
      const u8 *d = libusb_get_iso_packet_buffer_simple(ptTransfer, i);
      vLOG_STATIC_FUNC_VA("## AUDIO %d [%d] s=%d %d %d ## %02x %02x %02x %02x", iIndex, i, iStatus, iCount, iAudioDataCount, d[0],d[1],d[2],d[3]);

      iCount += iLength;
      if (1)
      {
        const u8 *pu8Data = libusb_get_iso_packet_buffer_simple(ptTransfer, i);
        vWriteData(pu8Data, iLength);
      }
    }
  }

  iAudioDataCount += iCount;
  libusb_submit_transfer(ptTransfer);
}

I am seeing some (presumably) real audio data received but also blocks of silence. In all cases, the first two iso packets report actual_length=0 (status = 0). The other packets all seem to report status = 0 and actual_length=192. But there quite a bit of silence along with the real audio data.

Any suggestions as to what I'm doing wrong ?

Note if I enable the kernel usb audio driver I can extract audio data correctly from this device (not via libusb).

Sample debug output showing the received iso packets

[1970-01-01 01:43:40.210950]   APK:  6
[1970-01-01 01:43:40.213641]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 11520 ## 00 00 00 00
[1970-01-01 01:43:40.216951]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 11520 ## 00 00 00 00
[1970-01-01 01:43:40.219735]   APK:  <>vAudioTransferCallback ## AUDIO 0 [1] s=0 192 11520 ## 00 00 00 00
[1970-01-01 01:43:40.223220]   APK:  <>vAudioTransferCallback ## AUDIO 0 [2] s=0 384 11520 ## 67 fa 87 fc
[1970-01-01 01:43:40.226307]   APK:  <>vAudioTransferCallback ## AUDIO 0 [3] s=0 576 11520 ## b0 05 18 04
[1970-01-01 01:43:40.229425]   APK:  <>vAudioTransferCallback ## AUDIO 0 [4] s=0 768 11520 ## 8c 01 8d 0a
[1970-01-01 01:43:40.232478]   APK:  <>vAudioTransferCallback ## AUDIO 0 [5] s=0 960 11520 ## fa 10 68 07
[1970-01-01 01:43:40.235584]   APK:  <>vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 11520 ## 37 fc a0 f6
[1970-01-01 01:43:40.238448]   APK:  <>vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 11520 ## 67 10 fb 11
[1970-01-01 01:43:40.241528]   APK:  <>vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 11520 ## fe 3e e4 2d
[1970-01-01 01:43:40.244246]   APK:  <>vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 11520 ## ab 27 0a 0c
[1970-01-01 01:43:40.248378]   APK:  7
[1970-01-01 01:43:40.251457]   APK:  <>vAudioTransferCallback ## AUDIO 1 [0] s=0 0 13440 ## 00 00 00 00
[1970-01-01 01:43:40.254397]   APK:  <>vAudioTransferCallback ## AUDIO 1 [0] s=0 0 13440 ## 00 00 00 00
[1970-01-01 01:43:40.257499]   APK:  <>vAudioTransferCallback ## AUDIO 1 [1] s=0 192 13440 ## 00 00 00 00
[1970-01-01 01:43:40.260553]   APK:  <>vAudioTransferCallback ## AUDIO 1 [2] s=0 384 13440 ## 14 17 2a 13
[1970-01-01 01:43:40.263494]   APK:  <>vAudioTransferCallback ## AUDIO 1 [3] s=0 576 13440 ## 00 00 00 00
[1970-01-01 01:43:40.266423]   APK:  <>vAudioTransferCallback ## AUDIO 1 [4] s=0 768 13440 ## 08 cc 7e e7
[1970-01-01 01:43:40.270542]   APK:  <>vAudioTransferCallback ## AUDIO 1 [5] s=0 960 13440 ## 2d 02 08 02
[1970-01-01 01:43:40.273383]   APK:  <>vAudioTransferCallback ## AUDIO 1 [6] s=0 1152 13440 ## cc 33 8c 17
[1970-01-01 01:43:40.276251]   APK:  <>vAudioTransferCallback ## AUDIO 1 [7] s=0 1344 13440 ## fe fb 58 01
[1970-01-01 01:43:40.279282]   APK:  <>vAudioTransferCallback ## AUDIO 1 [8] s=0 1536 13440 ## c0 1e fc 22
[1970-01-01 01:43:40.282025]   APK:  <>vAudioTransferCallback ## AUDIO 1 [9] s=0 1728 13440 ## f5 2d db 1b
[1970-01-01 01:43:40.285341]   APK:  8
[1970-01-01 01:43:40.287917]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 15360 ## 00 00 00 00
[1970-01-01 01:43:40.290592]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 15360 ## 00 00 00 00
[1970-01-01 01:43:40.293534]   APK:  <>vAudioTransferCallback ## AUDIO 0 [1] s=0 192 15360 ## 00 00 00 00
[1970-01-01 01:43:40.297206]   APK:  <>vAudioTransferCallback ## AUDIO 0 [2] s=0 384 15360 ## 00 00 00 00
[1970-01-01 01:43:40.299787]   APK:  <>vAudioTransferCallback ## AUDIO 0 [3] s=0 576 15360 ## 00 00 00 00
[1970-01-01 01:43:40.302547]   APK:  <>vAudioTransferCallback ## AUDIO 0 [4] s=0 768 15360 ## 00 00 00 00
[1970-01-01 01:43:40.305560]   APK:  <>vAudioTransferCallback ## AUDIO 0 [5] s=0 960 15360 ## 00 00 00 00
[1970-01-01 01:43:40.308276]   APK:  <>vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 15360 ## 00 00 00 00
[1970-01-01 01:43:40.311370]   APK:  <>vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 15360 ## 00 00 00 00
[1970-01-01 01:43:40.314361]   APK:  <>vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 15360 ## 00 00 00 00
[1970-01-01 01:43:40.317197]   APK:  <>vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 15360 ## 00 00 00 00
[1970-01-01 01:43:40.320896]   APK:  9
[1970-01-01 01:43:40.323373]   APK:  <>vAudioTransferCallback ## AUDIO 1 [0] s=0 0 17280 ## 00 00 00 00
[1970-01-01 01:43:40.326469]   APK:  <>vAudioTransferCallback ## AUDIO 1 [0] s=0 0 17280 ## 00 00 00 00
[1970-01-01 01:43:40.329211]   APK:  <>vAudioTransferCallback ## AUDIO 1 [1] s=0 192 17280 ## 00 00 00 00
[1970-01-01 01:43:40.332293]   APK:  <>vAudioTransferCallback ## AUDIO 1 [2] s=0 384 17280 ## 00 00 00 00
[1970-01-01 01:43:40.335149]   APK:  <>vAudioTransferCallback ## AUDIO 1 [3] s=0 576 17280 ## 00 00 00 00
[1970-01-01 01:43:40.338327]   APK:  <>vAudioTransferCallback ## AUDIO 1 [4] s=0 768 17280 ## 00 00 00 00
[1970-01-01 01:43:40.341078]   APK:  <>vAudioTransferCallback ## AUDIO 1 [5] s=0 960 17280 ## 00 00 00 00
[1970-01-01 01:43:40.344239]   APK:  <>vAudioTransferCallback ## AUDIO 1 [6] s=0 1152 17280 ## 00 00 00 00
[1970-01-01 01:43:40.347355]   APK:  <>vAudioTransferCallback ## AUDIO 1 [7] s=0 1344 17280 ## 00 00 00 00
[1970-01-01 01:43:40.350426]   APK:  <>vAudioTransferCallback ## AUDIO 1 [8] s=0 1536 17280 ## 00 00 00 00
[1970-01-01 01:43:40.353044]   APK:  <>vAudioTransferCallback ## AUDIO 1 [9] s=0 1728 17280 ## 00 00 00 00
[1970-01-01 01:43:40.356274]   APK:  10
[1970-01-01 01:43:40.358936]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 19200 ## 00 00 00 00
[1970-01-01 01:43:40.361895]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 19200 ## 00 00 00 00
[1970-01-01 01:43:40.364625]   APK:  <>vAudioTransferCallback ## AUDIO 0 [1] s=0 192 19200 ## 00 00 00 00
[1970-01-01 01:43:40.367423]   APK:  <>vAudioTransferCallback ## AUDIO 0 [2] s=0 384 19200 ## 00 00 00 00
[1970-01-01 01:43:40.370733]   APK:  <>vAudioTransferCallback ## AUDIO 0 [3] s=0 576 19200 ## 00 00 00 00
[1970-01-01 01:43:40.373669]   APK:  <>vAudioTransferCallback ## AUDIO 0 [4] s=0 768 19200 ## 00 00 00 00
[1970-01-01 01:43:40.376641]   APK:  <>vAudioTransferCallback ## AUDIO 0 [5] s=0 960 19200 ## 00 00 00 00
[1970-01-01 01:43:40.379476]   APK:  <>vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 19200 ## 00 00 00 00
[1970-01-01 01:43:40.382556]   APK:  <>vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 19200 ## 00 00 00 00
[1970-01-01 01:43:40.385597]   APK:  <>vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 19200 ## 00 00 00 00
[1970-01-01 01:43:40.388249]   APK:  <>vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 19200 ## 00 00 00 00
[1970-01-01 01:43:40.391605]   APK:  11
[1970-01-01 01:43:40.394268]   APK:  <>vAudioTransferCallback ## AUDIO 1 [0] s=0 0 21120 ## 00 00 00 00
[1970-01-01 01:43:40.397703]   APK:  <>vAudioTransferCallback ## AUDIO 1 [0] s=0 0 21120 ## 00 00 00 00
[1970-01-01 01:43:40.400550]   APK:  <>vAudioTransferCallback ## AUDIO 1 [1] s=0 192 21120 ## 00 00 00 00
[1970-01-01 01:43:40.403441]   APK:  <>vAudioTransferCallback ## AUDIO 1 [2] s=0 384 21120 ## 00 00 00 00
[1970-01-01 01:43:40.406244]   APK:  <>vAudioTransferCallback ## AUDIO 1 [3] s=0 576 21120 ## 00 00 00 00
[1970-01-01 01:43:40.409378]   APK:  <>vAudioTransferCallback ## AUDIO 1 [4] s=0 768 21120 ## 00 00 00 00
[1970-01-01 01:43:40.412248]   APK:  <>vAudioTransferCallback ## AUDIO 1 [5] s=0 960 21120 ## 00 00 00 00
[1970-01-01 01:43:40.415340]   APK:  <>vAudioTransferCallback ## AUDIO 1 [6] s=0 1152 21120 ## 00 00 00 00
[1970-01-01 01:43:40.418073]   APK:  <>vAudioTransferCallback ## AUDIO 1 [7] s=0 1344 21120 ## 00 00 00 00
[1970-01-01 01:43:40.421518]   APK:  <>vAudioTransferCallback ## AUDIO 1 [8] s=0 1536 21120 ## 00 00 00 00
[1970-01-01 01:43:40.424226]   APK:  <>vAudioTransferCallback ## AUDIO 1 [9] s=0 1728 21120 ## 00 00 00 00
[1970-01-01 01:43:40.427576]   APK:  12
[1970-01-01 01:43:40.430343]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 23040 ## 00 00 00 00
[1970-01-01 01:43:40.433348]   APK:  <>vAudioTransferCallback ## AUDIO 0 [0] s=0 0 23040 ## 00 00 00 00
[1970-01-01 01:43:40.436195]   APK:  <>vAudioTransferCallback ## AUDIO 0 [1] s=0 192 23040 ## 00 00 00 00
[1970-01-01 01:43:40.439210]   APK:  <>vAudioTransferCallback ## AUDIO 0 [2] s=0 384 23040 ## 00 00 00 00
[1970-01-01 01:43:40.441925]   APK:  <>vAudioTransferCallback ## AUDIO 0 [3] s=0 576 23040 ## ab f9 ed ef
[1970-01-01 01:43:40.444603]   APK:  <>vAudioTransferCallback ## AUDIO 0 [4] s=0 768 23040 ## 00 00 00 00
[1970-01-01 01:43:40.448085]   APK:  <>vAudioTransferCallback ## AUDIO 0 [5] s=0 960 23040 ## 23 e5 19 ef
[1970-01-01 01:43:40.451235]   APK:  <>vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 23040 ## 07 0a 82 f5
[1970-01-01 01:43:40.453757]   APK:  <>vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 23040 ## a7 06 84 02
[1970-01-01 01:43:40.456527]   APK:  <>vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 23040 ## c7 ed 0e 00
[1970-01-01 01:43:40.459447]   APK:  <>vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 23040 ## a4 03 b4 04

Thanks
John



Audio Partnership PLC, Gallery Court, Hankey Place, London SE1 4BB, UK Reg No. 2953313 This e-mail is confidential and for the addressee only. Please refer to Disclaimer for important notices.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
Xiaofan Chen | 8 May 12:21
Picon

openbsd_usb.c warnings under NetBSD

Hi Martin,

Maybe you want to take a look at the following warnings.
os/openbsd_usb.c: In function '_sync_control_transfer':
os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules

localhost$ ./autogen.sh
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
/usr/pkg/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is
expanded from...
/usr/pkg/share/aclocal/libtool.m4:4158: _LT_LINKER_SHLIBS is expanded from...
/usr/pkg/share/aclocal/libtool.m4:5233: _LT_LANG_C_CONFIG is expanded from...
/usr/pkg/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from...
/usr/pkg/share/aclocal/libtool.m4:67: LT_INIT is expanded from...
/usr/pkg/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
/usr/pkg/share/aclocal/libtool.m4:4158: _LT_LINKER_SHLIBS is expanded from...
/usr/pkg/share/aclocal/libtool.m4:5233: _LT_LANG_C_CONFIG is expanded from...
/usr/pkg/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from...
/usr/pkg/share/aclocal/libtool.m4:67: LT_INIT is expanded from...
/usr/pkg/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:1038: _LT_SYS_MODULE_PATH_AIX is expanded from...
aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:160: _LT_SETUP is expanded from...
aclocal.m4:89: LT_INIT is expanded from...
aclocal.m4:124: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:160: _LT_SETUP is expanded from...
aclocal.m4:89: LT_INIT is expanded from...
aclocal.m4:124: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:1038: _LT_SYS_MODULE_PATH_AIX is expanded from...
aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:160: _LT_SETUP is expanded from...
aclocal.m4:89: LT_INIT is expanded from...
aclocal.m4:124: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:160: _LT_SETUP is expanded from...
aclocal.m4:89: LT_INIT is expanded from...
aclocal.m4:124: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:1038: _LT_SYS_MODULE_PATH_AIX is expanded from...
aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:160: _LT_SETUP is expanded from...
aclocal.m4:89: LT_INIT is expanded from...
aclocal.m4:124: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:160: _LT_SETUP is expanded from...
aclocal.m4:89: LT_INIT is expanded from...
aclocal.m4:124: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:42: installing `./compile'
configure.ac:39: installing `./config.guess'
configure.ac:39: installing `./config.sub'
configure.ac:29: installing `./install-sh'
configure.ac:29: installing `./missing'
examples/Makefile.am: installing `./depcomp'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i386-unknown-netbsdelf6.0.
checking host system type... i386-unknown-netbsdelf6.0.
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... match_pattern
/lib[^/]+(\.so|_pic\.a)$
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... NetBSD ld.elf_so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for windres... no
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... NetBSD (using OpenBSD backend)
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking sys/timerfd.h usability... no
checking sys/timerfd.h presence... no
checking for sys/timerfd.h... no
checking whether TFD_NONBLOCK is declared... no
checking whether to use timerfd for timing... no (header not available)
checking for struct timespec... yes
checking for sigaction... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for gettimeofday... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
localhost$ make
make  all-recursive
Making all in libusb
  CC     libusb_1_0_la-core.lo
  CC     libusb_1_0_la-descriptor.lo
  CC     libusb_1_0_la-io.lo
  CC     libusb_1_0_la-sync.lo
  CC     libusb_1_0_la-openbsd_usb.lo
os/openbsd_usb.c: In function '_sync_control_transfer':
os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
  CC     libusb_1_0_la-threads_posix.lo
  CCLD   libusb-1.0.la
Making all in doc
Making all in examples
  CC     listdevs.o
  CCLD   listdevs
  CC     dpfp.o
  CCLD   dpfp
  CC     dpfp_threaded-dpfp_threaded.o
  CCLD   dpfp_threaded
localhost$ uname -a
NetBSD localhost.localdomain 6.0_BETA NetBSD 6.0_BETA (GENERIC) i386
localhost$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: i486--netbsdelf
Configured with:
/usr/src2/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=i486--netbsdelf --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html
--with-pkgversion='NetBSD nb2 20111202' --enable-__cxa_atexit
--with-arch=i486 --with-tune=nocona
--with-mpc=/var/obj/mknative/i386/usr/src2/destdir.i386/usr
--with-mpfr=/var/obj/mknative/i386/usr/src2/destdir.i386/usr
--with-gmp=/var/obj/mknative/i386/usr/src2/destdir.i386/usr
--enable-tls --disable-multilib --disable-symvers
--disable-libstdcxx-pch --build=x86_64-unknown-netbsd5.99.56
--host=i486--netbsdelf
Thread model: posix
gcc version 4.5.3 (NetBSD nb2 20110806)

--

-- 
Xiaofan

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Mysingen | 29 Apr 23:53
Picon

Polling file descriptors for synchronous transfers

Hello

I can't seem to find a solution to this anywhere, but it seems strange that
no one would have encountered this before. Please don't get mad if this
stuff is old hat:

I am writing a single threaded application that has a poll/select loop. I
don't need asynchronous USB transfers at all, but I do need to poll the file
descriptors associated with the USB device. This does not seem possible, or
is it?

Some pseudo code to give you some idea what's going on before the first
poll:

libusb_init(NULL)
libusb_device_handle * handle = discover_my_device() // discover, open &
claim the device
libusb_bulk_transfer(handle, endpoint OUT, message, ...) // the device will
write an answer back

Polling details:

short
poll_usb_fds(short events, int timeout)
{
    int i, count = 0;
    struct pollfd * fds;
    const struct libusb_pollfd ** list = libusb_get_pollfds(NULL);
    if (list == NULL) {
        printf("could not list pollable file descriptors\n");
        return -1;
    }
    for (i = 0; list[i] != NULL; i++) {
        count++;
        printf("may poll fd=%i events=0x%x\n", list[i]->fd,
list[i]->events);
    }
    fds = calloc(count, sizeof(struct pollfd));
    if (fds == NULL) {
        printf("calloc() failed\n");
        return -2;
    }
    for (i = 0; i < count; i++) {
        fds[i].fd     = list[i]->fd;
        fds[i].events = list[i]->events & events;
    }
    free(list);
    short r = poll(fds, count, timeout);
    printf("poll() = %i\n", r);
    for (i = 0; i < count; i++) {
        printf("fd=%i, revents=0x%x\n", fds[i].fd, fds[i].events);
    }
    free(fds);

    return r;
}

I call poll_usb_fds(POLLIN, 10000), and it NEVER returns before the timeout.
The OS poll() always returns zero, even though .revents=POLLIN for 2 of 3
file descriptors. What is going on?

The actual transfers work just fine, of course. System details:

$ uname -a
Linux seldlx0540 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:12:07 UTC
2012 x86_64 GNU/Linux

$ dpkg -s libusb-1.0-0
Package: libusb-1.0-0
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 124
Maintainer: Ubuntu Developers <ubuntu-devel-discuss <at> lists.ubuntu.com>
Architecture: amd64
Source: libusb-1.0
Version: 2:1.0.6-1
Depends: libc6 (>= 2.8)
Description: userspace USB programming library
 Library for programming USB applications without the knowledge
 of Linux kernel internals.
Original-Maintainer: Aurelien Jarno <aurel32 <at> debian.org>
Homepage: http://www.linux-usb.org/

Please help. This is a blocking issue for me :-(

BR / Mysingen

--
View this message in context: http://libusb.6.n5.nabble.com/Polling-file-descriptors-for-synchronous-transfers-tp5674722p5674722.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Mysingen | 30 Apr 00:57
Picon

Re: [C/C++] Use libusb with function poll() or select()

I have the same question. Would really appreciate an answer.

/Mysingen

--
View this message in context: http://libusb.6.n5.nabble.com/C-C-Use-libusb-with-function-poll-or-select-tp4396235p5674802.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Deron | 7 May 17:10
Favicon

Controlling and reading a usb radio

Hello,

I hope this is an appropriate things to post here. I have an AlertFM usb 
radio that is "windows only" that I want to use on my Ubuntu server. The 
plan is to set it up to listen for EAS warnings on our local radio 
station. (We live a long way from civilization and don't always have the 
TV on). If I can get the audio stream, I can do the rest easy enough 
(I've got that part written and tested using recordings of EAS audio 
messages).

Anyway, I have a windows computer and captured some channel changing 
data using their software, and digging around I found this software 
which actually recommends hidapi for HID devices. No problem, I have 
that installed along with libusb and I think I even have it changing 
channels (one report sets the channel, and another reads back the 
current channel. Still an input report I can't seem to grab which gives 
signal strength data etc, but I could live without that.)

What I don't have now is the audio stream. I'm not very familiar with 
USB, so this is a really basic question, but what do I do to read that 
data? I'm guessing that hidapi won't be able to read that data, and 
somehow need to mix in calls with libusb? I've not had much luck finding 
sample applications for hidapi, and if someone could just nudge me in 
the correct direction I would appreciate it or even basic info on USB 
that would fluff out my knowledge without have to read an encyclopedia 
on USB.

Thanks!

Deron

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Gmane