RFC: recording strategy on timer conflicts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christian Wieninger schrieb:

>Am Dienstag, 23. Mai 2006 18:30 schrieb Andreas Brugger:
>  
>
>>of the devices (first or last):
>>    
>>
>>>-  cDevice *d = NULL;
>>>+  cDevice *d = device[0]; // or device[numDevices]
>>>      
>>>
>>So the two timers should evaluate to different priorities.
>>
>>Any thoughts on that? Do I miss something again?
>>    
>>
>
>I think so ;-) because if d is set to first device then
>
>         else if (d && device[i]->Priority() < d->Priority())
>            pri = 6; // receiving but priority is lower
>
>the first loop does not match the if condition. It would work if d was 
>initially set to the last device. But I don't know if this would make 
>problems in any other cases.
>  
>
Ohhh ... right! I haven't thought that through completely it seems ... 
there is also a problem that the first (or last) device would be 
returned even if the devices doesn't provide the channel.

This isn't as easy as I thought ...


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux