4 Replies Latest reply on Dec 18, 2017 7:45 AM by Kendall Bennett

    Slow performance for Scanner.Data callbacks on TC8000

    Kendall Bennett

      Hi Guys,


      We are in the process of porting our C# code from Windows CE running on Intermec CN51 devices to Android using Xamarin running on both the CN51 devices as well as Zebra TC8000. Everything about these Zebra handhelds is awesome compared to the CN51's. They are just as light, feel great in the hand and the form factor when scanning is so much better than the CN51 units. However the software architecture they use for reading the scans is far from ideal. The problem is simple; speed.


      It is critical for our business applications that once someone scans an item that there is audible feedback immediately from the scanner about that scan. They scan products when receiving at very fast rates so we need the scanner to respond as quickly as possible so our software architecture makes sure all the relevant barcodes for expected products are loaded into the scanner locally so we do not need any network requests to determine if a scan is good or bad. And we turn off the internal beep on the scanner so we can play the correct sounds depending on the scanned item (normal, out of stock, just in time or error not found). With the CN51 scanners we get the callback from the scanner for the barcode scan instantly so it works very well.


      However with the Zebra scanners there is a perceptible delay from when you scan the items and our software actually receives the barcode scan and can process it via the Scanner.Data callback. The delay also seems to vary, and given that the callback to our code from the scanner software library passes in a ‘list’ of barcodes to process, it leads me to believe that the Zebra libraries have some kind of background thread that polls the scanner for barcodes and then passes all the scanned barcodes to us as a list on a regular basis. However clearly the response time is not good as there is a noticeable delay. The CN51 on the other hand I believe has a hardware interrupt that fires so we get called immediately when the hardware reads that scan (and we just get one of them, not a list).


      I can play around with potential solutions such as leaving the scanner beep in place, but in the past we found that was not optimal because the employee has to pay attention to two beeps for every item scanned. A scanner read beep (which happens instantly), and if there is an error or the item needs to be flagged then a second beep indicating the difference if it was not a regular item that needs no extra flagging. If we leave the internal scanner beep disabled, the delay between scanning the item and actually getting the audio feedback is going to slow down our work productivity immensely.


      I tried to get onto the Zebra support site so I can submit tickets, but to get there I need to sign up on the web site and apply for it (even though I am actively able to log into these forums). Which in itself is not an issue except that the final screen of the signup process requires me to enter a country using a country drop down, but the freaking drop down is empty! Grr. Someone needs to fix that ASAP.


      Anyway at the end of the day the software design of this library is severely lacking and we have ordered 10 of these units for a test deployment. If we can't get this sorted out, we will likely have to send them all back to our supplier and just get more of the existing CN51 units we have been using to date (which work great on Android and actually support Marshmallow 6.0 while the TC8000 is stuck at Lollipop 5.1).


      I scoured both the Xamarin API docs and the Java API docs to find anything to speed this process up, but so far have drawn a blank. Any help would be appreciated!

        • Re: Slow performance for Scanner.Data callbacks on TC8000
          Darryn Campbell

          Hi, that's an interesting read, most people report that our devices have superior scanning performance so it will be good to understand what is going on.


          Firstly, let me clear up a misconception, right now although the scanner onData method returns a list of scans you will only ever get a single scan returned in that list and there is no caching waiting for additional scans to occur.  Your application will receive scanned data immediately on scan with the default reader parameters.


          There are two aspects in this setup:

          1. The time taken to read the barcode and report this to your application

          2. The time to process that barcode and for the application to emit a sound.


          If the delay is happening at step 1 I suspect this could be related to the configuration of your scanner.  I suggest comparing with the performance of GitHub - Zebra/samples-emdkforandroid-6_6 at BarcodeSample1  which just writes the barcodes to the screen.

          If the delay is happening at step 2, which API are you using to emit the audio?  Perhaps there is a more immediate way to output audio.

            • Re: Slow performance for Scanner.Data callbacks on TC8000
              Kendall Bennett

              So I ended up spending quite a bit of time working out what was going on and used the sample program to compare the scanning speed to my code and found the latency between scanning and the barcode data callback was not the issue. The real issue turns out to be really crappy audio performance on the zebra handheld units and this is either a software issue with your drivers or an issue with android lollipop itself. When we get a barcode scan we play our own sounds rather than relying on the scanner beep because we play different sounds depending on whether the scan was good or not (IE incorrect product for order or invoice etc), or whether the person using the device needs to do something special with that product (hot pick item etc).


              To play the sounds which are in wave files, we have been using the android MediaPlayer class. On the CN51 devices that are using Android 6.0 marshmallow the sounds play immediately. On the zebra there is a noticable delay that actually varies somewhat between scans. I was able to verify that by adding my sound code to the barcode sample app and could see the barcode and count showing on the screen long before the sound played.


              Googling around it seems I am not the only one who has had performance issues with MediaPlayer on android so perhaps this is something fixed in 6.0 so the CN51 works better, or maybe they just have much better audio drivers.


              In an attempt to solve the problem I spent some time writing my own sound player based on the lower level AudioTrack class which plays decoded sound streams. I wrote some code to parse the wave files into the raw audio to play via the AudioTrack class and the latency is much, much better. However even using the AudioTrack class if I wire up a button on the screen to play a beep sound comparing the two devices the CN51 plays the sound almost instantly while the Zebra still has a noticeable delay.


              If it is possible to get some help on the Zebra side I would be more than happy to modify the barcode sample app to include both a MediaPlayer based sound player and my AudioTrack player and upload it to git so you can compile it yourself to see what I am talking about. If this problem could be solved it would be huge for us as we have been planning to replace our entire fleet of CN51 devices with the TC8000 but we can’t afford to have terrible latency when a scan is made and we play the sounds.


              Also if there is another mechanism to play wave file custom sounds more efficiently on the TC8000 I would love to learn about it.

                • Re: Slow performance for Scanner.Data callbacks on TC8000
                  Darryn Campbell

                  Hi, it sounds like you are doing all the right things.  I am glad the issue is isolated to audio output rather than the scanner performance .  Although I don't see anything specific from Google on the subject I see 3rd party websites reporting that Marshmallow audio performance is superior to Lollipop so perhaps it is an improvement made in Android - as the delta between the two devices reduces with your AudioTrack test other differences will likely come into play as you say like processor, drivers etc.  It really is a rabbit hole when you look into Audio performance on Android, it's not something I have developed in the past.


                  Given the level of technical support required at this stage in your investigation I think it would be best if you go through your supplier or account manager to request official Zebra support.  When the questions get into driver level details it would typically require engineering involvement and there is a process for that which is always expedited by the possibility of replacing competitor devices. 


                  It would be great if somebody knowledgeable in Audio Android development can respond here but as I say, you may have more luck going through your account.