Simplify 'rec_play->state` in sds_rec_play

[ReinhardKeil]

I suggest to review this module with pair programming.

IMHO the rec_play->state should be a simple variable that can have the following values:

#define SDS_RECPLAY_STATE_INACTIVE 0 // data stream unused
#define SDS_RECPLAY_STATE_OPENING 1 // open function is processed
#define SDS_RECPLAY_STATE_PLAY 2 // data stream is in play (read) mode
#define SDS_RECPLAY_STATE_REC 3 // data stream is in recording (write) mode
#define SDS_RECPLAY_CLOSING 4 // close function is processed

Using this states should make:

• simplify the overall code (it can be only one value, not multiple flags).
• stream_type obsolete (such a variable should be named mode for consistency).

rec_play->flags seems to be another state (somehow duplicates). It could be perhaps mapped to the state, i.e. by using

#define SDS_RECPLAY_STATE_EOS 5 // data stream read end of stream in play (read) mode

[DavidLesnjak]

While a single state variable may seem simpler, the current design — where stream state is packed into individual bytes — was intentionally chosen to enable atomic byte access.

This design is used to cover multithreaded scenarios like the following, where different threads (e.g., writer and closer) need to safely coordinate without interfering with each other's state updates.
If a single variable (e.g., an enum or bitfield) were used instead, it would require a locking mechanism to prevent race conditions during concurrent read-modify-write operations.

Example: sdsRecClose starts, then sdsRecWrite is called shortly after

Time	Thread	Action	closing	rw_active	Effect
T0	Thread A	sdsRecClose() is called	→ 1	0	Signals stream is closing
T1	Thread A	Waits for rw_active == 0	1	0	Proceeding to notify background thread for final flush
T2	Thread B	sdsRecWrite() is called	1	→ 1	Sets rw_active = 1, enters write
T3	Thread B	Checks closing == 1	1	1	Write aborted due to closing state
T4	Thread B	Clears rw_active = 0	1	→ 0	Write safely exits without corrupting stream state
T5	Thread A	Sees rw_active == 0, continues	1	0	Safe to proceed with closing logic (flush buffer, etc.)

I suggest keeping current implementation with states packed into individual bytes.

I agree with changing stream_type to mode

[ReinhardKeil]

Thanks for explaining.

Sorry, I still believe we need to review this code one more time.
A while loop like here https://github.com/ARM-software/SDS-Framework/blob/main/sds/source/sds_rec_play.c#L515
can be toxic when the thread that calls sdsRecClose has a higher priority then the thread that calls sdsRecWrite.

Maybe a mutex should be used to protect that multiple threads execute the same function.