This discussion is archived
1 2 Previous Next 21 Replies Latest reply: Sep 8, 2012 3:55 AM by 898586 Go to original post RSS
  • 15. Re: Multiplicity
    898586 Newbie
    Currently Being Moderated
    OK, thanks. Then :
                                  Set<Map.Entry<String, ClientMic>> entries = cchmCM.entrySet();
                             for (Map.Entry<String, ClientMic> e : entries) {
                                  e.getValue().ccLinkQ.offer(dgPacketMIC);
                             }
    is essentially what the producer contributes, (cchmCM being all the consuming threads, and ccLinkQ their Queues), and :
    if(!(ccLinkQ.isEmpty())){                         
    
                             dPack.setData((ccLinkQ.poll()).getData());
                             audio_send.send(dPack);
                             Thread.yield();
                                                      
                        }
    is the consumer, in which dPack is its DatagramPacket, ccLinkQ of course the Queue, and audio_send the DatagramSocket.

    Reasonable?
  • 16. Re: Multiplicity
    jtahlborn Expert
    Currently Being Moderated
    895583 wrote:
    if(!(ccLinkQ.isEmpty())){                         
    
                             dPack.setData((ccLinkQ.poll()).getData());
                             audio_send.send(dPack);
                             Thread.yield();
                                                      
                        }
    Reasonable?
    No, you should be using a BlockingQueue. the producer calls put() or offer() (depending on the guarantees you want) and the consumer calls take(). as a general rule, if you find your self using poll(), sleep(), or yield() in multi-threaded code, you are doing it wrong.
  • 17. Re: Multiplicity
    898586 Newbie
    Currently Being Moderated
    That's interesting, and helpful. However changing over to a BlockingQueue in the form of a LinkedBlockingQueue, one per consumer, produced flakier voice between just two peers than my previous ConcurrentLinkedQueue where you entered this question.

    The participation of the third voice peer made the QOS a sight worse still. Strangely, when I opened Task Manager to look quickly if the CPU might be melting down, TM's load choked the throughput and produced a much better voice connection. With the infrastructure seemingly in place for the rest of the housekeeping in the app., it's a pity that this looks like a timing issue that can't be tamed without a whole load more knowledge on my part.
  • 18. Re: Multiplicity
    jtahlborn Expert
    Currently Being Moderated
    895583 wrote:
    That's interesting, and helpful. However changing over to a BlockingQueue in the form of a LinkedBlockingQueue, one per consumer, produced flakier voice between just two peers than my previous ConcurrentLinkedQueue where you entered this question.

    The participation of the third voice peer made the QOS a sight worse still. Strangely, when I opened Task Manager to look quickly if the CPU might be melting down, TM's load choked the throughput and produced a much better voice connection. With the infrastructure seemingly in place for the rest of the housekeeping in the app., it's a pity that this looks like a timing issue that can't be tamed without a whole load more knowledge on my part.
    my guess would be (and you could probably confirm this with some debugging on either end) is that when you use the blockingqueue, you end up sending more packets (in both directions) and, unless you are doing some ordering (since you are using UDP), you're probably getting more jumbled packets on either end as they fight w/ each other over the network (and/or more traffic on the network is causing lossier overall connections).

    Edited by: jtahlborn on Sep 7, 2012 4:12 PM
  • 19. Re: Multiplicity
    898586 Newbie
    Currently Being Moderated
    Not that I can pronounce meaningfully on it, (least not yet), but your comment sounds quite plausible. I've almost had more debugging in the code than code itself at times, but I'd have to say that I wouldn't know what else I could debug that I haven't tried already. For example, the thread reads and writes seem perfectly interlaced; but that (I guess) has almost nothing to do with the sequence(s) in which the packets are delivered or received(?).

    And as for attempting any ordering on the packets, I can't see what kind of a handle one could get on the packets to do such a thing - the fields in the packet are all no-nos, and so this line of thinking leaves me up a blind alley. Seems to be where art and science formally part company this one.
  • 20. Re: Multiplicity
    jtahlborn Expert
    Currently Being Moderated
    895583 wrote:
    Not that I can pronounce meaningfully on it, (least not yet), but your comment sounds quite plausible. I've almost had more debugging in the code than code itself at times, but I'd have to say that I wouldn't know what else I could debug that I haven't tried already. For example, the thread reads and writes seem perfectly interlaced; but that (I guess) has almost nothing to do with the sequence(s) in which the packets are delivered or received(?).

    And as for attempting any ordering on the packets, I can't see what kind of a handle one could get on the packets to do such a thing - the fields in the packet are all no-nos, and so this line of thinking leaves me up a blind alley. Seems to be where art and science formally part company this one.
    you could add a sequence number to your packets on the sending end (add a 4 byte prefix), and see what comes out on the other side.
  • 21. Re: Multiplicity
    898586 Newbie
    Currently Being Moderated
    Want to thank you both for assisting here.

    Do you think there could be any merit in my trying to deal with or mitigate heterogeneous packet collisions (ie. packets from different peers in the conversation) on the receiving (Speaker / SourceDataLine end)? I was thinking of inserting an identifier (not a sequence number) into the packet (in the 4-byte area for instance), which is then used to sort into Queues at reception and then output to the audio line? (According to what folk such as EJP have commented to me elsewhere, collisions are somehow inevitable, yet I'm conjecturing that homogeneous collisions are not as serious, since when only two clients are speaking in my app., there is enough continuity there for reasonable acceptability).

    Would it be worth breaking up the receiver into Queues is the question.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points