I found a MIDI file which I don't know how to interpret, it starts something like this:
Tick: 384
NOTE ON
Channel: 1
Velocity: 127
Pitch: 53
Tick: 672
NOTE ON
Channel: 1
Velocity: 127
Pitch: 53
Tick: 768
NOTE OFF
Channel: 1
Velocity: 85
Pitch: 53
I noticed at least 1 MIDI player seem to take the middle ON and interpret it as a NOTE OFF then NOTE ON at same tick, is that correct behavior? I suspect it is but I want to be sure.
From the MIDI spec:
ASSIGNMENT OF NOTE ON/OFF COMMANDS
If an instrument receives two or more Note On messages with the same key number and MIDI channel, it must make a determination of how to handle the additional Note Ons. It is up to the receiver as to whether the same voice or another voice will be sounded, or if the messages will be ignored. The transmitter, however, must send a corresponding Note Off message for every Note On sent. If the transmitter were to send only one Note Off message, and if the receiver in fact assigned the two Note On messages to different voices, then one note would linger. Since there is no harm or negative side effect in sending redundant Note Off messages this is the recommended practice.
VOICE ASSIGNMENT IN POLY MODE
In Poly mode there are no particular rules which define how to assign voices when more than one Note On message is received and recognized. If more Note On messages are transmitted than the receiver is capable of playing, the receiver is free to use any method of dealing with this "overflow" situation (such as first vs. last note priority). The priority of voice assignments may follow the order in which Note On messages are received, the receiver's own keyboard control logic, or some other scheme.
When a transmitter sends Note On and Off information to a receiving keyboard which is also being played, it is important for the receiver to distinguish the source of Note On/Off information. For example, a Note Off received from MIDI should not turn off a note that is being played on the receiver's own keyboard. Conversely, releasing a key on the receiver's own keyboard should not turn off a note being received from MIDI.
So I suppose every method is appropriate.
Related
UDP packets obviously can arrive multiple times, not at all and out of order.
But if packets arrive, is it guaranteed, that any call to recvfrom and similar functions will return exactly one complete packet the sender sent via sendto (or similar)? In other words, is it possible to receive incomplete packets or multiple packets at once? Is it dependent on the OS, or does the standard mandate a certain behavior?
As I mentioned in a comment, the UDP specification (RFC 768) does not specify the behavior of the "interface" between an application program and the OS infrastructure that handles UDP messages.
However, POSIX specification does address this. The key section of the recvfrom spec says this:
The recvfrom() function shall return the length of the message written to the buffer pointed to by the buffer argument. For message-based sockets, such as SOCK_RAW, SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded.
Note the use of the word "shall". Any OS <-> application API that claims to conform to the POSIX spec would be bound by that language.
In simple terms, any POSIX compliant recvfrom will return one complete UDP message in the buffer provided that the buffer space provided is large enough. If it is not large enough, "excess" bytes will be discarded.
(Some recvfrom implementations support a non-standard MSG_TRUNC flag that allows the application to find out the actual message length. Check the OS-specific manual page for details.)
The recv family of system calls don't behave like that. They do not return frames or packets, they transfer layer 3 payload bytes stored in the processor's internal receive buffers to the user applications buffer. In other words, what ultimately determines how many bytes are passed up is the size of the user's buffer. The behaviour is to try and fill this buffer and if that's not possible to send what data has arrived and if that's not possible then block or return no data depending on how the recv is configured.
From the recv man page (my emphasis)
If a message is too long to fit in the supplied buffer,
excess bytes may be discarded depending on the type of socket the
message is received from.
If no messages are available at the socket, the receive calls wait
for a message to arrive, unless the socket is nonblocking (see
fcntl(2)), in which case the value -1 is returned and the external
variable errno is set to EAGAIN or EWOULDBLOCK. The receive calls
normally return any data available, up to the requested amount,
rather than waiting for receipt of the full amount requested.
The one other factor that needs to be taken into account is the internal recive buffer size. This is a fixed size and attempting to add more data to an already full buffer can result in loss of data. The value can be set with the SO_RCVBUF flag - from the socket man page:
SO_RCVBUF Sets or gets the maximum socket receive buffer in bytes. The
kernel doubles this value (to allow space for bookkeeping
overhead) when it is set using setsockopt(2), and this doubled
value is returned by getsockopt(2). The default value is set
by the /proc/sys/net/core/rmem_default file, and the maximum
allowed value is set by the /proc/sys/net/core/rmem_max file.
The minimum (doubled) value for this option is 256.
1) How many types of call holds are there in SIP/VOIP?
2) Does SDP parameter changes for reinvite during call hold?
3) Does RTP packets flow during call hold?
How many types of call holds are there in SIP/VOIP?
Two main types are recognised, Attended and Blind.
Attended is where you call and speak to the transfer destination first.
Blind is where you instruct the transferee to call the destination without the introduction.
Does SDP parameter changes for reinvite during call hold?
Normally yes. The media flow SDP attribute will typically change from sendrecv to sendonly/recvonly/inactive depending on how call hold is implemented.
Another common way to put a call on hold is to play on hold music and in that case the SDP may not need to change at all. It's a simple substitution of audio capture input for music.
Does RTP packets flow during call hold?
Depends on how the call hold is implemented. If the media flow attribute is used then RTP will normally stop flowing in one or both directions.
If it's done with music on hold RTP will keep flowing in the original manner.
I am new to STM32 and freertos. I need to write a program to send and receive data from a module via UART port. I have to send(Transmit) a data to that module(for eg. M66). Then I would return to do some other tasks. once the M66 send a response to that, my seial-port-receive-function(HAL_UART_Receive_IT) has to be invoked and receive that response. How can I achieve this?
The way HAL_UART_Receive_IT works is that you configure it to receive specified amount of data into given buffer. You give it your buffer to which it'll read received data and number of bytes you want to receive. It then starts receiving data. Once exactly this amount of data is received, a callback function HAL_UART_RxCpltCallback gets called (from IRQ) where you can do whatever you want with this data, e.g. add it to some kind of queue for later processing in the task context.
If I was to express my experiences related to working with HAL's UART module is that it's not the greatest one for generic use where you don't know the amount of data you expect to receive in advance. In the case of M66 modem you mention, this will happen all the time.
To solve this you have two choices:
Simply don't use HAL functions at all in case of UART, other than the initialization functions. Implement your own UART interrupt handler (most of the code can be copied from handler in HAL) where upon receiving data you place received bytes in a receive byte queue handled in your RTOS task. In this task you implement protocol parsing. This is the approach I use personally.
If you really want to use HAL but also work with a module that sends varying amount of data, call HAL_UART_Receive_IT and specify that you want to receive 1 byte each time. This will work, but will be (potentially much) slower than the first approach. Assuming you'll later want to implement some tcp/ip communication (you mentioned M66 GPRS module) you probably don't want to do it this way.
You should try the following way.
Enable UARTX Rx interrupt in NVIC.
Set Interrupt priority.
Unmask Interrupt request in EXTI.
Then use USARTX Interrupt Handler Function Define in you Vector.
Whenever the data is received from USARTX this function get automatically called and you can copy data from USARTX Receive Data Register.
I would rather suggest another approach. You probably want to archive higher speeds (lets say 921600 bods) and the interrupt way is fat to slow for it.
You need to implement the DMA transmition with the data end detection features. Run your USART in the DMA mode in the circular mode. You will have two events to serve. The first one is the DMA end of thransmition interrupt (then you copy the data from the current tail pointer to the end of the buffer to avoid data override) and USART IDLE interrupt - this will detect the end of the receive.
I have configured a UART to receive in DMA mode where the size of the buffer is around 64 bytes. So, basically, the HAL_UART_RxCpltCallback() DMA receive complete interrupt will only fire when 64 chars are received.
Is there a way in STM32 through which I can configure a timeout for DMA Rx where when the buffer is only partially filled (i.e. less than 64 chars are received) and we don't receive anymore chars for a specified timeout, the DMA will then raise the same HAL_UART_RxCpltCallback() based interrupt to let the consumer consume whatever partial data is currently received on the UART?
You can use the UART Idle detection interrupt in parallel to the DMA interrupt.
I have used this multiple times with ST32F0xx processors and it is working perfectly.
There Idle detection should be available on F4 and F7 processors too.
There are some tutorials in the internet which target your problem and also provide the solution with the Idle detection.
E.g. check out this one this one.
It's easy but you have to use USART receiver timeout interrupt instead.
in order to get a count of transferred bytes, you can use DMA_CNDTRx or DMA_SxNDTR register (name different for STM family, where x - channel number ).
This register decrements after each DMA transfer. Once the transfer is completed, this register can either stay at zero or be reloaded automatically by the value previously programmed if the channel is configured in autoreload mode.
Unfortunately, STM HAL doesn't provide API, you should implement it yourself.
I pretty much understand how the CAN protocol works -- when two nodes attempt to use the network at the same time, the lower id can frame gets priority and the other node detects this and halts.
This seems to get abstracted away when using socketcan - we simply write and read like we would any file descriptor. I may be misunderstanding something but I've gone through most of the docs (http://lxr.free-electrons.com/source/Documentation/networking/can.txt) and I don't think it's described unambiguously.
Does write() block until our frame is the lowest id frame, or does socketcan buffer the frame until the network is ready? If so, is the user notified when this occurs or do we use the loopback for this?
write does not block for channel contention. It could block because of the same reasons a TCP socket write would (very unlikely).
The CAN peripheral will receive a frame to be transmitted from the kernel and perform the Medium Access Control Protocol (MAC protocol) to send it over the wire. SocketCAN knows nothing about this layer of the protocol.
Where the frame is buffered is peripheral/driver dependent: the chain kernel-driver-peripheral behaves as 3 chained FIFOs with their own control flow mechanisms, but usually, it is the driver that buffers (if it is needed) the most since the peripheral has less memory available.
It is possible to subscribe for errors in the CAN stack protocol (signaled by the so called "error frames") by providing certain flags using the SocketCAN interface (see 4.1.2 in your link): this is the way to get error information at application layer.
Of course you can check for a correctly transmitted frame by checking the loopback interface, but it is overkill, the error reporting mechanism described above should be used instead and it is easier to use.